> I think this is something this discussion has been seriously missing;
> input from some of those who really will be deciding this:
> - Linus Torvalds and other kernel developers (Alan's been involved a bit,
> though).
> Well, not that anything I saw is official in any way, but I've been
> keeping quite because I've been amazed how stupid most of the UDI
> discussion has been.
> Let's back off and have a fresh perspective on things.
> First of all, from looking at the UDI spec, UDI drivers will likely not
> be as performant as "native" drivers. So there will still be incentives
> for people who want device drivers for Linux to actually go and write
> them, and for those people to pester manufactuers for specifications.
> (Or reverse-engineer or disassemble the UDI driver for programming
> information. :-)
Yes. But if you CAN NOT use new card it BY FAR better reason to write
native driver/demand specs then if you CAN but driver is slow.
> Secondly, UDI drivers will almost certainly be loadable kernel modules,
> using a fixed, and well defined interface. Linus (as the main copyright
> holder of the Linux kernel) has already said that loadable kernel
> modules which restrict themselves to the kernel interface as defined by
> /proc/ksyms are considered separate entities, and are not covered by the
> GPL copyright --- just as user programs which use the normal kernel
> system calls are not considered part of the kernel, but using normal
> kernel services. So all of the copyright arguments are also a red
> herring.
Correct.
> Furthermore, what do you think the APM code in the Linux kernel does?
> It makes calls to the APM BIOS! Or the Linux Bootstrap code, which
> makes calls to the system BIOS. The System BIOS and the APM BIOS are
> not GPL'ed on most systems --- indeed, source code is usually not
> available in any form. Why is this not a problem?
It IS PROBLEM. Look at APM support in linux kernel -- there are quite a
few workarounds for buggy APM BIOS'es. And it's only one, simple part of
system (and in the end you could just turn APM off)! If all devices will
require such workarounds then life will ne nightmare (exactly like it's
in Windows just now :-)
> Well, let's think about it. The System BIOS and APM BIOS have a
> well-defined, and standardized interface. When you buy a computer, it
> comes with BIOS installed on ROM's as a matter of course. So the fact
> that the System BIOS and the APM BIOS are not free doesn't get people's
> way, and they probably simply don't think about it.
APM BIOS usage could be turned off if you want (the same about PCI BIOS in
2.1.1xx :-). System BIOS is used only on system startup and not used
afterwards so System BIOS does not alter your system stability...
> Similarly, suppose now that network cards start coming with UDI drivers
> on a diskette as a matter of course. The UDI device driver uses a
> standardized, well-defined interface --- the UDI interface. It really
> isn't all that different from the Linux kernel calling system BIOS
> routines, or the APM routines.
Yes. But instead of System BIOS (mostly ignored anyway -- used only on bootup),
APM BIOS (could be turned off) and PCI BIOS (finally not needed in 2.1.1xx)
Linux kernel developers will be forced to cope with zillions of buggy UDI
drivers. I'm not sure that there are enough kernel hackers to handle this
task :-((
> So fundamentally, I don't have a problem with the UDI concept --- just
> as I don't have a problem with purchasing commercial software to run on
> my Linux box. I am not an Open Source fanatic. All other things being
> equal, I prefer Open Source, of course, but if a Open Source product
> doesn't exist, and there is a good propietary solution available, I will
> use it.
Yes. And IMO inclusion OSD-conformant licensing of drivers as one of USD
conformance criteria is "right way". Even if "Big Boss"es are not aware
about Open Source (end even about drivers :-) at all they are aware that
certified driver is "good thing" and non-certified driver is "bad thing".
If there are will be no choices (I2O stuff) they will buy hardware with
non-certified drivers ("conditionally certified" drivers?); where they will
have choice certified drivers will be chosen so manufacturers who will
publish specs or will help write open-source drivers will got direct
benefit from their opennes...
> The big question, though is the quality of the UDI reference
> implementation which SCO is planning on writing. WIll it be clean
> enough so that Linus is willing to include it in the mainline kernel?
> That's the $64,000 question. If it's big, ugly, etc., then the answer
> will be no. And of course, the UDI reference implementation which will
> actually *allow* the Linux kernel to take advantage of UDI drivers will
> have to be GPL'ed, since that *will* be linked with the kernel in a very
> fundamental way. But as far as I can tell, SCO understands that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/