Re: misc questions about the devicedriver arch
does that mean that whenever a new device or a new driver is add to the system ,a corresponding deviceclass will equally be created, am i right ,sir? Yes. That's right. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: misc questions about the devicedriver arch
From: william wallace [EMAIL PROTECTED] Subject: Re: misc questions about the devicedriver arch Date: Sat, 20 May 2006 13:39:08 +0800 comparing the method array of pci_pci and cardbusbridge: what losts in pci bridge but exist in cardbusbridge: 1 card interface 2 power interface 3 some functions : 3ain bus interface (bus_driver_added, cbb_driver_added), (bus_child_detached,cbb_child_detached), (bus_child_present, cbb_child_present), 3b in device interface (device_detach, cbb_detach), what exists in pci bridge but losts in cardbusbridge: (pcib_route_interrupt, pcib_route_interrupt), not only that ,functions r very different eventhough they realize the same interface function template wooo，so long to go to hotplug pci Yes. The hardest part would be to create a pci hot swap bridge driver. The interface for them tend to be underdocumented. The bus_child_present is important for detaching. Also, I think that we may need to start implementing a quiess method to tell the drivers they are about to be removed. For hot plug PCI, the model is that you quess the driver, the os tells you somehow it is safe, and then you remove the card. The details vary (some system are all in software, while others have a complicated interlock and LEDs), but they are similar. Cardbus is harder in some ways because cards leave unannounced (in fact, there's not a good way to announce a card leaving, but there should be). Warner On 5/20/06, Warner Losh [EMAIL PROTECTED] wrote: Busses create devices to represent hardware in the system. The bus then causes these devices to be probed and attached. This latter usage is for those cases. As drivers are loaded these devices are offered to the new (and old) drivers in the system. FreeBSD inherently dynamic in its device system. The hardest part of adding hotplug support is programming the bridge. Adding new devices to the tree is easy, but knowing when to add them is hard since you have to write a bridge driver... Warner -- we who r about to die,salute u! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Inconsistency in LC_CTYPE source files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, It came to my attention that some LC_CTYPE source files for UTF-8, UTF-8.src and zh_TW.UTF-8.src, are inconsistent with all other LC_CTYPE source files. The literals in all other LC_CTYPE source files, including am_ET.UTF-8.src, are written in the native byte sequence of that specific locale, whereas UTF-8.src and zh_TW.UTF-8.src are written in Unicode (It must be noted that UTF-8 is NOT the same as Unicode.). This creates headaches for locale-aware applications supporting UTF-8. For example, the usages and behaviors of the is*() and isw*() functions, like iswspace(), are different under all other locales including am_ET.UTF-8 and under other UTF-8 locales. Under all other locales including am_ET.UTF-8, the argument for the isw*() functions is the wide character literal in that locale, whereas under other UTF-8 locales the application must first convert the wide character from UTF-8 to Unicode before feeding into the isw*() functions. Is there any good reason to have such inconsistency? Shall we change UTF-8.src and zh_TW.UTF-8.src so that the behaviors are consistent with other locales? Sincerely, Li-Lun Wang -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEb1D7CQM7t5B2mhARAgMEAJ9FMpNx1IaUGIn0NNBaaHLj3DFQqACbBSJg tWnXCT2N15U+SntjmuTrGjI= =JNXG -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: NFS server not responding prevents boot
Um that is what intr is for - and it won't cause silent data loss. -Kip On 5/19/06, Sergey Babkin [EMAIL PROTECTED] wrote: From: Steven Hartland [EMAIL PROTECTED] Anyway the big question is how can I change all our NFS mounts so that failed mounts dont prevent the machines booting to the point where they can be fixed remotely i.e. have started sshd. Doh!! spent ages googling for the answer then found it in 2mins of looking through the man pages. The option for anyone interested is bg for -b from the command line to mount: [quote=man mount_nfs] -b If an initial attempt to contact the server fails, fork off a I usually use soft,bg. The soft option makes the operations on this filesystem fail if the server is not available instead of hanging (unkillable!) forever and waiting for the server to come up. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Source Screensaver
Hi all, Doubts ! I created to screensaver for console. The code would like to know as sending, to be enclosed in src of the FreeBSD. Thanks, Eder. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: misc questions about the devicedriver arch
still a question about newbus 's BUS interface : usage of DEVICE_IDENTIFY AND BUS_ADD_CHILD I know these bus interface func r called accessor functions ,that call the appropriate function by checking the parameter.just like the polymorphism technic in OOP . that's really a magic :) my first QUESTION is what if the calling device do not realize the corresponding interface ? taking bus_add_child interface as example. only a few device-drivers have implement it ,but more r called for it .what will happen when BUS_ADD_CHILD(device_t bus, int order, const char *name, int unit) 's bus do not implement it ? my second is :a driver's DEVICE_IDENTIFY always call its device 's parent's BUS_ADD_CHILD ,what is the semantic of them:) thank u the drivers who have registered the bus_add_child (not too many) Acpi.c (dev\acpica):DEVMETHOD(bus_add_child,acpi_add_child), Atkbdc_isa.c (isa): DEVMETHOD(bus_add_child,atkbdc_add_child), Canbus.c (pc98\pc98): DEVMETHOD(bus_add_child,canbus_add_child), Firewire.c (dev\firewire): DEVMETHOD(bus_add_child, firewire_add_child), Fwohci_pci.c (dev\firewire):DEVMETHOD(bus_add_child, fwohci_pci_add_child), Iicbus.c (dev\iicbus):DEVMETHOD(bus_add_child, iicbus_add_child), Isa_common.c (isa): DEVMETHOD(bus_add_child,isa_add_child), Legacy.c (amd64\amd64): DEVMETHOD(bus_add_child,legacy_add_child), Legacy.c (i386\i386): DEVMETHOD(bus_add_child,legacy_add_child), Nexus.c (amd64\amd64): DEVMETHOD(bus_add_child,nexus_add_child), Nexus.c (i386\i386):DEVMETHOD(bus_add_child,nexus_add_child), Nexus.c (ia64\ia64):DEVMETHOD(bus_add_child,nexus_add_child), Ppbconf.c (dev\ppbus): DEVMETHOD(bus_add_child,ppbus_add_child), Smbus.c (dev\smbus):DEVMETHOD(bus_add_child,smbus_add_child), On 5/20/06, Warner Losh [EMAIL PROTECTED] wrote: From: william wallace [EMAIL PROTECTED] Subject: Re: misc questions about the devicedriver arch Date: Sat, 20 May 2006 13:39:08 +0800 comparing the method array of pci_pci and cardbusbridge: what losts in pci bridge but exist in cardbusbridge: 1 card interface 2 power interface 3 some functions : 3ain bus interface (bus_driver_added, cbb_driver_added), (bus_child_detached,cbb_child_detached), (bus_child_present, cbb_child_present), 3b in device interface (device_detach, cbb_detach), what exists in pci bridge but losts in cardbusbridge: (pcib_route_interrupt, pcib_route_interrupt), not only that ,functions r very different eventhough they realize the same interface function template wooo，so long to go to hotplug pci Yes. The hardest part would be to create a pci hot swap bridge driver. The interface for them tend to be underdocumented. The bus_child_present is important for detaching. Also, I think that we may need to start implementing a quiess method to tell the drivers they are about to be removed. For hot plug PCI, the model is that you quess the driver, the os tells you somehow it is safe, and then you remove the card. The details vary (some system are all in software, while others have a complicated interlock and LEDs), but they are similar. Cardbus is harder in some ways because cards leave unannounced (in fact, there's not a good way to announce a card leaving, but there should be). Warner On 5/20/06, Warner Losh [EMAIL PROTECTED] wrote: Busses create devices to represent hardware in the system. The bus then causes these devices to be probed and attached. This latter usage is for those cases. As drivers are loaded these devices are offered to the new (and old) drivers in the system. FreeBSD inherently dynamic in its device system. The hardest part of adding hotplug support is programming the bridge. Adding new devices to the tree is easy, but knowing when to add them is hard since you have to write a bridge driver... Warner -- we who r about to die,salute u! -- we who r about to die,salute u! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: misc questions about the devicedriver arch
william wallace wrote this message on Sun, May 21, 2006 at 10:42 +0800: still a question about newbus 's BUS interface : usage of DEVICE_IDENTIFY AND BUS_ADD_CHILD I know these bus interface func r called accessor functions ,that call the appropriate function by checking the parameter.just like the polymorphism technic in OOP . that's really a magic :) my first QUESTION is what if the calling device do not realize the corresponding interface ? taking bus_add_child interface as example. only a few device-drivers have implement it ,but more r called for it .what will happen when BUS_ADD_CHILD(device_t bus, int order, const char *name, int unit) 's bus do not implement it ? If there isn't one implemented, it just falls back to kobj_error_method, which simply returns ENXIO... my second is :a driver's DEVICE_IDENTIFY always call its device 's parent's BUS_ADD_CHILD ,what is the semantic of them:) thank u the drivers who have registered the bus_add_child (not too many) Acpi.c (dev\acpica):DEVMETHOD(bus_add_child, acpi_add_child), Atkbdc_isa.c (isa): DEVMETHOD(bus_add_child,atkbdc_add_child), Canbus.c (pc98\pc98): DEVMETHOD(bus_add_child,canbus_add_child), Firewire.c (dev\firewire):DEVMETHOD(bus_add_child, firewire_add_child), Fwohci_pci.c (dev\firewire): DEVMETHOD(bus_add_child, fwohci_pci_add_child), Iicbus.c (dev\iicbus):DEVMETHOD(bus_add_child, iicbus_add_child), Isa_common.c (isa): DEVMETHOD(bus_add_child,isa_add_child), Legacy.c (amd64\amd64): DEVMETHOD(bus_add_child, legacy_add_child), Legacy.c (i386\i386): DEVMETHOD(bus_add_child,legacy_add_child), Nexus.c (amd64\amd64):DEVMETHOD(bus_add_child, nexus_add_child), Nexus.c (i386\i386): DEVMETHOD(bus_add_child,nexus_add_child), Nexus.c (ia64\ia64): DEVMETHOD(bus_add_child,nexus_add_child), Ppbconf.c (dev\ppbus):DEVMETHOD(bus_add_child, ppbus_add_child), Smbus.c (dev\smbus):DEVMETHOD(bus_add_child, smbus_add_child), Look at how it's called: nclaptop,ttyp5,~/FreeBSD/HEAD/src/sys/isa,557$grep BUS_ADD_CHILD * isahint.c: child = BUS_ADD_CHILD(parent, order, name, unit); orm.c: child = BUS_ADD_CHILD(parent, ISA_ORDER_SENSITIVE, orm, -1); as you can see, you just provide the probe order, the name and unit of the device you're adding... The call to BUS_ADD_CHILD is necessary for busses that use identify methods... this ensures that things like ivars are setup properly by the bus for the device.. On 5/20/06, Warner Losh [EMAIL PROTECTED] wrote: From: william wallace [EMAIL PROTECTED] Subject: Re: misc questions about the devicedriver arch Date: Sat, 20 May 2006 13:39:08 +0800 comparing the method array of pci_pci and cardbusbridge: what losts in pci bridge but exist in cardbusbridge: 1 card interface 2 power interface 3 some functions : 3ain bus interface (bus_driver_added, cbb_driver_added), (bus_child_detached,cbb_child_detached), (bus_child_present, cbb_child_present), 3b in device interface (device_detach, cbb_detach), what exists in pci bridge but losts in cardbusbridge: (pcib_route_interrupt, pcib_route_interrupt), not only that ,functions r very different eventhough they realize the same interface function template wooo?$B!$so long to go to hotplug pci Yes. The hardest part would be to create a pci hot swap bridge driver. The interface for them tend to be underdocumented. The bus_child_present is important for detaching. Also, I think that we may need to start implementing a quiess method to tell the drivers they are about to be removed. For hot plug PCI, the model is that you quess the driver, the os tells you somehow it is safe, and then you remove the card. The details vary (some system are all in software, while others have a complicated interlock and LEDs), but they are similar. Cardbus is harder in some ways because cards leave unannounced (in fact, there's not a good way to announce a card leaving, but there should be). On 5/20/06, Warner Losh [EMAIL PROTECTED] wrote: Busses create devices to represent hardware in the system. The bus then causes these devices to be probed and attached. This latter usage is for those cases. As drivers are loaded these devices are offered to the new (and old) drivers in the system. FreeBSD inherently dynamic in its device system. The hardest part of adding hotplug support is programming the bridge. Adding new devices to the tree is easy, but knowing when to add them is hard since you have to write a bridge driver... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list
