Being honest with MODULE_LICENSE [LWN.net]

Being honest with MODULE_LICENSE

Posted Apr 28, 2004 16:52 UTC (Wed) by rknop (guest, #66)
Parent article: Being honest with MODULE_LICENSE

Although the issue may sound trivial/harmless to people on the lkml, it was a frequent cause of confusion for the average person.

This is a good thing. There is a real danger of Linux working too cleanly and easily for the common user with proprietary kernel modules and with hardware that can't be supported by free software. Specifically, the drive to have any open-source supported hardware goes away. We've already basically got this with video cards; as far as I can tell, no video card manufacturer is supplying programming information any more. Rather, any recent video card requires proprietary drivers if you want to use 3d acceleration. (Somebody please prove me wrong.) The fact that so many distributions make it easy to do this means that only the fanatics like me and kernel developers notice any more.

If we can use licensing requirements to at least let the people who otherwise wouldn't notice realize that they're making a compromise, it might help avoid, or at least slow, completely damping out the motivation for there to be open source drivers for hardware.

-Rob

to post comments

Being honest with MODULE_LICENSE

Posted May 10, 2004 17:30 UTC (Mon) by elanthis (guest, #6227) [Link] (3 responses)

"There is a real danger of Linux working too cleanly and easily for the common user"

That comment (yes, taken out of context) is pretty much exactly how many users, administrators, and developers already see Linux, thanks entirely the fact that it is already so hard to use proprietary drivers, and in fact even most Open Source drivers. The fact that any driver not distributed with the kernel itself is very difficult to use, thanks entirely to constantly changing ABI and API, makes it very difficult to just use new hardware. The only way to get things to work is to upgrade the kernel or the local driver source.

Most Linux drivers aren't available separately from the kernel release cycle, so in fact your only option with Open Source drivers is to upgrade the kernel, re-apply any local patches, rebuilding initrd images, reinstall any proprietary drivers, update the boot loader, etc. Again, for absolutely no good reason.

Using _any_ hardware, no matter the driver, is a pita on Linux, and will continue to be so until the kernel offers (at the very least) a stable API across the same release series (and preferably backwards compatibility across the major release serieis). A stable ABI would make life even easier. Again, this isn't just proprietary drivers, it's also affecting Open Source drivers.

Being honest with MODULE_LICENSE

Posted Jun 22, 2021 18:10 UTC (Tue) by scientes (guest, #83068) [Link] (2 responses)

While a stable ABI is non-sense, it would be nice if Linux wasn't such a security mess and could put its drivers is user-space.

Being honest with MODULE_LICENSE

Posted Jun 22, 2021 19:40 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

What be even nicer is if OS's *in general* took advantage of the cpu's ring mechanism. I think I've got it the right way round, the OS runs in privileged ring 0 mode, and userspace runs in unprivileged ring 3.

That gives us unused rings 1 and 2, and I would have thought that's the perfect place for drivers and all that stuff. Or is the problem like that with micro-kernels - the context switch is just too expensive?

Cheers,
Wol

Being honest with MODULE_LICENSE

Posted Jun 23, 2021 4:28 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

1) Many CPUs just have a user/supervisor split rather than multiple rings
2) Even on x86, you can't set page access at a finer grain than "available to ring 3" and "not available to ring 3" - anything running in rings 1 or 2 can scribble over any RAM that's in their page tables, so the meaningful benefit is marginal. The only way to have more granularity is to use segments instead of pages, and segments don't really exist in 64-bit mode, so. I guess in theory you could have ring 0 code load a different set of page tables whenever it transitions to ring 1 code, and then have ring 1 trigger a special syscall or whatever to indicate that it was done and could transition back to ring 0, but the overhead of that sounds like it'd be large?