Hi! > > > N_HCI activates (registers the hci dev) on HCIUARTSETPROTO ioctl. A child > > > device would need a way to specify the protocol I resume. > > > N_MOUSE activates on a 'read' on the tty - and deactivates when the read > > > completes. > > > N_GSM0710 activates immediately that the ldisc is activated, as does N_IRDA > > > N_PPP seems to want a PPPIOCNEWUNIT ioctl to fully register. > > > > > > Doing any of these in a driver for a uart slave device would certainly be > > > possible. I wonder if it is something we really want to do in the kernel > > > though. What is the gain over providing sufficient information in the > > > KOBJ_ADD uevent so that udev can do the required work in user-space? > > > > Consistency. If you have bluetooth on USB, it automatically works, > > without userspace help. If we have mouse on USB, it automatically > > works, etc... > > My point is: why is the kernel/userspace distinction important? As long as > it "automatically works", does it really matter where the code is? For some cases, it does, as "devices needed during boot". Someone is going to attach keyboard or something powermanagement related, sooner or later. > We can put a little bit of code in the kernel (to report the details of the > attached device) and a little bit of code in udev (to run hciattach) and it > will still be automatic. Of course, that's also possible. There will be parameters such as speed / parity / flow control that will need to be passed, and userland will still see /dev/ttySX device that it perhaps does not need to see. And there will be problems with devices such as bcm2048 on Nokia, which is connected by a serial line and (interrupt capable) GPIO lines and clocks. Rather than extending hciattach to pass the neccessary GPIO/clock information and extending udev to pass GPIO/clock information to hciattach (and extending kernel to pass it to udev and accept from hciattach), it makes sense to just do it internally. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
