On Friday 28 October 2005 11:30, Mark Jenkins wrote:
> I have read, http://people.redhat.com/arjanv/COPYING.modules
> Summary: A Linux module is a derivative work unless a strong case is
> made otherwise.
>
> I would like to know if this is one of those exception cases. That is
> why I used the word 'not' in the subject line.
>
> Is sharpzdc_cs.o *not* a derivative work of Linux?
I suspect that right now the Linux developers are trying an end-run around the
whole mess. At a wild guess, binary-only modules will probably be obsolete
in a few years. I could easily be wrong, but here's why I think this:
2.6 introduced sysfs and udev. When /dev is maintained by udev, then udev
gets the list of devices and each device's major/minor numbers from the dev
entry for the device in sysfs. At boot time, udev starts with an empty /dev
directory (generally tmpfs) and populates it from /sys, and hotplug events
tell udev to take another look at sysfs. I.E. if devices don't show up
in /sys, then udev doesn't create device nodes for them in /dev.
Of course you can work around this by running a supplemental script at boot
time to manually create extra devices (using the static major/minor numbers
from the lanana.org list), or by simply not using udev at all (and thus not
having modern features like good hotplug and persistent naming of things that
move around on USB hubs and such). The ability to use something other than
udev depends on the existence of static major and minor numbers.
But static major and minor numbers are not required for udev. Any system that
has udev recreates the contents of /dev from scratch on each reboot, and does
so based on major/minor pairs handed to it by sysfs. Those numbers can be
dynamically allocated by the kernel as each new device is hotplugged in,
there's no need for them to be preassigned.
At some point in the future, a config option will probably show up to make all
device numbers dynamically assigned. (This used to be a plan for 2.7, back
when we were going to have a 2.7.) For purely technical reasons, it's a
great simplifiation, making a lot of hardcoded magic numbers in the kernel
simply go away, eliminating the need to manage the hugely complex lanana.org
device number list, increasing scalability because now there's no real limit
on how many devices of a given type you can plug in since you won't run out
of major/minor pairs from the preallocated range to represent the new type.
It's been discussed before, and is a to-do item.
Of course under a dynamic major/minor scheme, udev would no longer be optional
but a requirement, and any device that wants a dev node _must_ show up in
sysfs or there's no major/minor pair to assign to it. And the really
interesting bit is that all the kernel-side sysfs bindings are
EXPORT_GPL_ONLY. A non-gpl module _cannot_ show up in sysfs. Thus under a
dynamic major/minor scheme, binary only modules couldn't have device nodes.
Interesting, isn't it? The normal churn in the kernel naturally renders old
interfaces obsolete, but the new interfaces are GPL_ONLY. Even if this isn't
the specific way they get rendered obsolete, the window for binary only
modules is slowly closing...
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
