|
|
Log in / Subscribe / Register

Managing dynamic device naming

Managing dynamic device naming

Posted May 2, 2004 15:48 UTC (Sun) by RicoWSuaveIII,Esq (guest, #21321)
Parent article: Managing dynamic device naming

Every system having private device naming schemes seems like a M$ conspiracy to put GNU/Linux out of commission ;-)

Userspace? Fine. But the naming scheme just *has* to be uniform over all systems and all distros. Let the kernel implement policy in these cases. It is a reasonable way to enforce uniformity (major and minor numbers are policy too! ;)

How can the kernel get away from using policy altogether, and still insert device drivers as pluggable modules? (and we don't want hardware access strictly in userland!) I don't want the kernel having to consult text files for this! That's ridiculous.

One repeated argument for devfs (applies to udev now too) is that progs can scan the fs to discover if a device is present. If you change the naming, then you lose the capability. Your "special" distro has to alter every app to look for devices in your "special" places.

Besides, if you had to have your own personal device naming scheme (foreseeably necessary for a super-secure router or some such) you could take advantage of the openness of the source. In closed source, separation of policy and mechanism is much more important. With open source, hard-coding certain policies is necessary to maintain compatibility (which everyone I've heard speak, thinks is the biggest obstacle to open source).

About serialization of the udev processes to eliminate race conditions:

It seems to me that locks or semaphores could be used to eliminate this problem. Until a device has been removed, the device name cannot be reused. Of course, this *needs* to be stored in (or at least be changed from) userspace, so that ophaned locks or semaphores can be dealt with (when processes die without running their cleanup routines, or when orphans are created by bugs).

If the locks or semaphores are stored in the kernel, then an interface could be provided to some userspace program for fixing incorrectly locked states. (It's the kernel, so reentry isn't too important unless you're using smp, right? Even with clustering, machines don't share a single kernel image in memory, right? --Correct me, please, if I'm mistaken)


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds