Re: binary drivers and development
Albert Cahalan <[EMAIL PROTECTED]> writes: > Lennart Sorensen writes: > > > You forgot the very important: > >- Only works on architecture it was compiled for. So anyone not > > using i386 (and maybe later x86-64) is simply out of luck. What do > > nvidia users that want accelerated nvidia drivers for X DRI do > > right now if they have a powerpc or a sparc or an alpha? How about > > porting Linux to a new architecture. With binary drivers you now > > start out with no drivers on the new architecture except for the > > ones you have source for. Not very productive. > > Rik van Riel writes: > > > No, it wouldn't. I can use a source code driver on x86, > > x86-64 and PPC64 systems, but a binary driver is only > > usable on the architecture it was compiled for. > > > > Source code is way more portable than binary anything. > > The kernel already has an AML interpreter for ACPI. **duck** > > As for portability, AML would do the job. It beats typical > vendor source code IMHO, because endianness and integer size > are well-defined. (like the Java VM and .net) Last I looked the kernel implemented opcodes that were not in the ACPI spec. So I would go with defined, but not well defined. Eric - 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/
Re: binary drivers and development
At 12:01 AM 3/13/2005 -0500, John Richard Moser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You wanna give me a quick run-down on x86 of CPL and Ring levels? It's been bugging me. I know they're there and have a basic idea that they control what a context can do, don't know what CPL stands for, and there's a visible gap in my knowledge. I like to understand everything, it makes things easier. http://appzone.intel.com/literature/index.asp to locate the Intel processor of your choice, or http://developer.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol1 for P4. -Mike - 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/
Re: binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You wanna give me a quick run-down on x86 of CPL and Ring levels? It's been bugging me. I know they're there and have a basic idea that they control what a context can do, don't know what CPL stands for, and there's a visible gap in my knowledge. I like to understand everything, it makes things easier. Felipe Alfaro Solana wrote: > On Thu, 10 Mar 2005 17:32:39 -0500, John Richard Moser > <[EMAIL PROTECTED]> wrote: > >>CPL=3 scares me; context switches are expensive. can they have direct >>hardware access? I'm sure a security model to isolate user mode drivers >>could be in place. . . >> >>. . . huh. Xen seems to run Linux at CPL=3 and give direct hardware >>access, so I guess user mode drivers are possible *shrug*. Linux isn't >>a microkernel though. > > > Xen hypervisor runs at Ring0, while the guest OSs it supports run at Ring1. > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCM8kShDd4aOud5P8RAon1AKCLNWEbY3Vq32k61m9jN2CbSoD98QCeJT8m mhgyXtmGNFL+RPzJw8md9hE= =B/i5 -END PGP SIGNATURE- - 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/
Re: binary drivers and development
On Thu, 10 Mar 2005 17:32:39 -0500, John Richard Moser <[EMAIL PROTECTED]> wrote: > CPL=3 scares me; context switches are expensive. can they have direct > hardware access? I'm sure a security model to isolate user mode drivers > could be in place. . . > > . . . huh. Xen seems to run Linux at CPL=3 and give direct hardware > access, so I guess user mode drivers are possible *shrug*. Linux isn't > a microkernel though. Xen hypervisor runs at Ring0, while the guest OSs it supports run at Ring1. - 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/
Re: binary drivers and development
Ben Dooks wrote: > On Thu, Mar 10, 2005 at 05:45:22PM -0500, Rik van Riel wrote: > > No, it wouldn't. I can use a source code driver on x86, > > x86-64 and PPC64 systems, but a binary driver is only > > usable on the architecture it was compiled for. > > Add to that the flavours of ARM and the number of > bootloaders that are out there. you need visions: let us define the 1k buswith MMIX aware VM driver model... Bene - 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/
Re: binary drivers and development
On Thu, 10 Mar 2005 12:24:15 -0500, John Richard Moser <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I've done more thought, here's a small list of advantages on using > binary drivers, specifically considering UDI. You can consider a > different implementation for binary drivers as well, with most of the > same advantages. Think about the impact the evolution of devfs and sysfs have on the driver model. They are still evolving. Or the 32 to 64 bit impact on ioctl's. -- Jon Smirl [EMAIL PROTECTED] - 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/
Re: binary drivers and development
On Thu, Mar 10, 2005 at 05:45:22PM -0500, Rik van Riel wrote: > On Thu, 10 Mar 2005, John Richard Moser wrote: > > > A Linux specific binary driver format might be more useful, > > No, it wouldn't. I can use a source code driver on x86, > x86-64 and PPC64 systems, but a binary driver is only > usable on the architecture it was compiled for. Add to that the flavours of ARM and the number of bootloaders that are out there. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - 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/
Re: binary drivers and development
Lennart Sorensen writes: > You forgot the very important: >- Only works on architecture it was compiled for. So anyone not > using i386 (and maybe later x86-64) is simply out of luck. What do > nvidia users that want accelerated nvidia drivers for X DRI do > right now if they have a powerpc or a sparc or an alpha? How about > porting Linux to a new architecture. With binary drivers you now > start out with no drivers on the new architecture except for the > ones you have source for. Not very productive. Rik van Riel writes: > No, it wouldn't. I can use a source code driver on x86, > x86-64 and PPC64 systems, but a binary driver is only > usable on the architecture it was compiled for. > > Source code is way more portable than binary anything. The kernel already has an AML interpreter for ACPI. **duck** As for portability, AML would do the job. It beats typical vendor source code IMHO, because endianness and integer size are well-defined. (like the Java VM and .net) For the x86 and ia64 users, the AML interpreter is probably already compiled into the kernel. Most people need it to set up SMP or power management. So, no added bloat even. AML code is fairly well controlled and isolated. There is of course the backdoor via DMA for the truly determined evil author, but such paranoia is rather extreme. AML is really designed for this sort of task. As with any interpreter, there are ways (JIT) to make the AML interpreter go faster if need be. - 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/
Re: binary drivers and development
On Thu, 10 Mar 2005, John Richard Moser wrote: > A Linux specific binary driver format might be more useful, No, it wouldn't. I can use a source code driver on x86, x86-64 and PPC64 systems, but a binary driver is only usable on the architecture it was compiled for. Source code is way more portable than binary anything. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - 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/
Re: binary drivers and development
On Thu, 2005-03-10 at 16:42 -0500, John Richard Moser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > People are still e-mailing me about this? You really expect to post something that inflammatory and have the emails stop after a few hours? Lee - 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/
Re: binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Chubb wrote: >>"John" == John Richard Moser <[EMAIL PROTECTED]> writes: > > > > John> I've done more thought, here's a small list of advantages on > John> using binary drivers, specifically considering UDI. You can > John> consider a different implementation for binary drivers as well, > John> with most of the same advantages. > > Almost all these advantages are also present for user-mode drivers... > and getting drivers out of the kernel, where possible, is a much > better approach IMHO than trying to maintain a leaky in-kernel > interface. The problem with in-kernel interfaces, even if set in > concrete, is that any binary driver can go outside the interface --- > there's no encapsulation --- and so break when the kernel changes. > CPL=3 scares me; context switches are expensive. can they have direct hardware access? I'm sure a security model to isolate user mode drivers could be in place. . . . . . huh. Xen seems to run Linux at CPL=3 and give direct hardware access, so I guess user mode drivers are possible *shrug*. Linux isn't a microkernel though. > Peter C > > > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFCMMsGhDd4aOud5P8RAjoOAJ9Owgnd5QOp9MfrQ8PzOLAt/A7k+wCYmxLc wvXLkQX84Z2PF2J4oEIbVA== =wi8f -END PGP SIGNATURE- - 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/
Re: binary drivers and development
> "John" == John Richard Moser <[EMAIL PROTECTED]> writes: John> I've done more thought, here's a small list of advantages on John> using binary drivers, specifically considering UDI. You can John> consider a different implementation for binary drivers as well, John> with most of the same advantages. Almost all these advantages are also present for user-mode drivers... and getting drivers out of the kernel, where possible, is a much better approach IMHO than trying to maintain a leaky in-kernel interface. The problem with in-kernel interfaces, even if set in concrete, is that any binary driver can go outside the interface --- there's no encapsulation --- and so break when the kernel changes. Peter C - 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/
Re: binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 People are still e-mailing me about this? Lennart Sorensen wrote: > On Thu, Mar 10, 2005 at 12:24:15PM -0500, John Richard Moser wrote: > >>I've done more thought, here's a small list of advantages on using >>binary drivers, specifically considering UDI. You can consider a >>different implementation for binary drivers as well, with most of the >>same advantages. >> >> - Smaller kernel tree >> The kernel tree would no longer contain all of the drivers; they'd >> slowly have to bleed into UDI until most were there > > > Users would have to go hunting for drivers to add to their kernel to get > hardware supported. Making a CD with a kernel and drivers for a wide > variety of hardware would be a nightmare. > /pub/kernel/2.6 /pub/drivers/ > >> - Better focused development >> The kernel's core would be the core. Driver code would be isolated, >> so work on the kernel would affect the kernel only and not any >> drivers. UDI is a standard interface that shouldn't be broken. This >> means that work on the high-level drivers will not need to be sanity >> checked a thousand times against the PCI Bus interface or the USB >> host controler API or whatnot. > > > But anything that runs in kernel memory space can still go trampling on > memory in the kernel by accident and is very difficult to debug without > the sources. > True, but that only should happen if you code things to access exact memory locations, rather than asking the kernel for memory or mappings. > >> - Faster rebuilding for developers >> The isolation between drivers and core would make rebuilding involve >> the particular component (driver, core). A "broken driver" would >> just require recoding and rebuilding the driver; a "broken kernel" >> would require building pretty much a skeletal core > > > That can already be done basicly. The makefiles work just fine for > rebuilding only what has changed in general. > I don't remember what I was thinking > >> - UDI supplies SMP safety >> The UDI page brags[1]: >> >> "An advanced scheduling model. Multiple driver instances can be run >>in parallel on multiple processors with no lock management performed >>by the driver. Free paralllism and scalability!" >> >> Drivers can be considered SMP safe, apparently. Inside the same >> driver, however, I have my doubts; I can see a driver maintaining a >> linked list that needs to be locked during insertions or deletions, >> which needs lock managment for the driver. Still, no consideration >> for anything outside the driver need be made, apparently. >> - Vendor drivers and religious issues >> Vendors can supply third party drivers until there are open source >> alternatives, since they have this religious thing where they don't >> want people to see their driver code, which is kind of annoying and >> impedes progress > > > I imagine a driver writer could still easily do something not SMP safe, > but I don't know that for sure. It sounds like a very complex thing to > promise a perfect solution for. > internally drivers would need to be smp safe, eh. Externally I guess they're safe. > >>Disadvantages: >> >> - Preemption >> Is it still possible to implement a soft realtime kernel that >> responds to interrupts quickly? >> - Performance >> UDI's developers claim that the performance overhead is negligible. >> It's still added work, but it remains to be seen if it's significant >> enough to degrade performance. >> - Religious battles >> People have this religious thing about binary drivers, which is kind >> of annoying and impedes progress > > > Many of the disadvantages are a good reason why they have these opinions > on binary drivers. They do impede getting work done if you have to use > them on your system and something isn't working right. > > >> - Constriction >> This would of course create an abstraction layer that constricts the >> driver developer's ability to do low level complex operations for any >> portable binary driver > > > You forgot the very important: >- Only works on architecture it was compiled for. So anyone not > using i386 (and maybe later x86-64) is simply out of luck. What do > nvidia users that want accelerated nvidia drivers for X DRI do > right now if they have a powerpc or a sparc or an alpha? How about > porting Linux to a new architecture. With binary drivers you now > start out with no drivers on the new architecture except for the > ones you have source for. Not very productive. > > [snip] > yeah, I was thinking the open source drivers would be ubiquitous to all architectures anyway though. Closed drivers would be subject to lazy venders. > Len Sorensen > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They should
Re: binary drivers and development
On Thu, Mar 10, 2005 at 12:24:15PM -0500, John Richard Moser wrote: > I've done more thought, here's a small list of advantages on using > binary drivers, specifically considering UDI. You can consider a > different implementation for binary drivers as well, with most of the > same advantages. > > - Smaller kernel tree >The kernel tree would no longer contain all of the drivers; they'd >slowly have to bleed into UDI until most were there Users would have to go hunting for drivers to add to their kernel to get hardware supported. Making a CD with a kernel and drivers for a wide variety of hardware would be a nightmare. > - Better focused development >The kernel's core would be the core. Driver code would be isolated, >so work on the kernel would affect the kernel only and not any >drivers. UDI is a standard interface that shouldn't be broken. This >means that work on the high-level drivers will not need to be sanity >checked a thousand times against the PCI Bus interface or the USB >host controler API or whatnot. But anything that runs in kernel memory space can still go trampling on memory in the kernel by accident and is very difficult to debug without the sources. > - Faster rebuilding for developers >The isolation between drivers and core would make rebuilding involve >the particular component (driver, core). A "broken driver" would >just require recoding and rebuilding the driver; a "broken kernel" >would require building pretty much a skeletal core That can already be done basicly. The makefiles work just fine for rebuilding only what has changed in general. > - UDI supplies SMP safety >The UDI page brags[1]: > >"An advanced scheduling model. Multiple driver instances can be run > in parallel on multiple processors with no lock management performed > by the driver. Free paralllism and scalability!" > >Drivers can be considered SMP safe, apparently. Inside the same >driver, however, I have my doubts; I can see a driver maintaining a >linked list that needs to be locked during insertions or deletions, >which needs lock managment for the driver. Still, no consideration >for anything outside the driver need be made, apparently. > - Vendor drivers and religious issues >Vendors can supply third party drivers until there are open source >alternatives, since they have this religious thing where they don't >want people to see their driver code, which is kind of annoying and >impedes progress I imagine a driver writer could still easily do something not SMP safe, but I don't know that for sure. It sounds like a very complex thing to promise a perfect solution for. > Disadvantages: > > - Preemption >Is it still possible to implement a soft realtime kernel that >responds to interrupts quickly? > - Performance >UDI's developers claim that the performance overhead is negligible. >It's still added work, but it remains to be seen if it's significant >enough to degrade performance. > - Religious battles >People have this religious thing about binary drivers, which is kind >of annoying and impedes progress Many of the disadvantages are a good reason why they have these opinions on binary drivers. They do impede getting work done if you have to use them on your system and something isn't working right. > - Constriction >This would of course create an abstraction layer that constricts the >driver developer's ability to do low level complex operations for any >portable binary driver You forgot the very important: - Only works on architecture it was compiled for. So anyone not using i386 (and maybe later x86-64) is simply out of luck. What do nvidia users that want accelerated nvidia drivers for X DRI do right now if they have a powerpc or a sparc or an alpha? How about porting Linux to a new architecture. With binary drivers you now start out with no drivers on the new architecture except for the ones you have source for. Not very productive. [snip] Len Sorensen - 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/
[Fwd: Re: binary drivers and development]
Forwarded Message > From: John Richard Moser <[EMAIL PROTECTED]> > To: Diego Calleja <[EMAIL PROTECTED]> > Cc: linux-kernel@vger.kernel.org > Subject: Re: binary drivers and development > Date: Thu, 10 Mar 2005 15:14:27 -0500 > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Stop mailing me, I lost interest when I figured out nobody else cared. you actually had to mail lkml and pollute it to find out that nobody cares about helping binary drivers? - 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/
Re: binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stop mailing me, I lost interest when I figured out nobody else cared. Diego Calleja wrote: > El Thu, 10 Mar 2005 12:24:15 -0500, > John Richard Moser <[EMAIL PROTECTED]> escribió: > > [...] > >> - Smaller kernel tree > > [...] > >> - Better focused development > > [...] > >> - Faster rebuilding for developers > > > It can be done without UDI. > > Then do so. > >>- UDI supplies SMP safety > > > Well designed drivers don't have SMP issues either... > I figured as much but *shrug* > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMKqihDd4aOud5P8RAqifAJ0aH26fq/x6AatH5S2ji2PRCsbOrQCgkGht xKVJ2rbkE+WGxCkGqyqrckM= =nQYU -END PGP SIGNATURE- - 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/
Re: binary drivers and development
El Thu, 10 Mar 2005 12:24:15 -0500, John Richard Moser <[EMAIL PROTECTED]> escribió: [...] > - Smaller kernel tree [...] > - Better focused development [...] > - Faster rebuilding for developers It can be done without UDI. > - UDI supplies SMP safety Well designed drivers don't have SMP issues either... - 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/
Re: binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Baechle wrote: > On Thu, Mar 10, 2005 at 11:28:39AM -0500, John Richard Moser wrote: > > >>I've been looking at the UDI project[1] and thinking about binary >>drivers and the like, and wondering what most peoples' take on these are >>and what impact that UDI support would have on the kernel's development. > > > UDI is already dead. You just haven't noticed. And just like with dead > people it's death also had a cause :-) > File last modified: 11:28 Tue December 14, 2004 3 months and it's dead. Linux hasn't passed 2.6 in over 3 months, it must be dead too :) > Ralf > - > 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/ > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMIMEhDd4aOud5P8RAvHzAJ99xQyr4SF98zd7VbmcSDCsEUEpFgCePAP8 7WdLwkOCKXkaycLNdL8KBbI= =o68B -END PGP SIGNATURE- - 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/
Re: binary drivers and development
On Thu, Mar 10, 2005 at 12:19:39PM -0500, John Richard Moser wrote: > Greg KH wrote: > > Please, the UDI stuff has been proven to be broken and wrong. If you > > want to work on it, feel free to do so, just don't expect for anyone to > > accept the UDI layer into the kernel mainline. > > 1. What's broken about it > 2. Is it possible to fix it > > I require information or else I can't assess things. Please do your own research on why the UDI project failed. greg k-h - 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/
Re: binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've done more thought, here's a small list of advantages on using binary drivers, specifically considering UDI. You can consider a different implementation for binary drivers as well, with most of the same advantages. - Smaller kernel tree The kernel tree would no longer contain all of the drivers; they'd slowly have to bleed into UDI until most were there - Better focused development The kernel's core would be the core. Driver code would be isolated, so work on the kernel would affect the kernel only and not any drivers. UDI is a standard interface that shouldn't be broken. This means that work on the high-level drivers will not need to be sanity checked a thousand times against the PCI Bus interface or the USB host controler API or whatnot. - Faster rebuilding for developers The isolation between drivers and core would make rebuilding involve the particular component (driver, core). A "broken driver" would just require recoding and rebuilding the driver; a "broken kernel" would require building pretty much a skeletal core - UDI supplies SMP safety The UDI page brags[1]: "An advanced scheduling model. Multiple driver instances can be run in parallel on multiple processors with no lock management performed by the driver. Free paralllism and scalability!" Drivers can be considered SMP safe, apparently. Inside the same driver, however, I have my doubts; I can see a driver maintaining a linked list that needs to be locked during insertions or deletions, which needs lock managment for the driver. Still, no consideration for anything outside the driver need be made, apparently. - Vendor drivers and religious issues Vendors can supply third party drivers until there are open source alternatives, since they have this religious thing where they don't want people to see their driver code, which is kind of annoying and impedes progress Disadvantages: - Preemption Is it still possible to implement a soft realtime kernel that responds to interrupts quickly? - Performance UDI's developers claim that the performance overhead is negligible. It's still added work, but it remains to be seen if it's significant enough to degrade performance. - Religious battles People have this religious thing about binary drivers, which is kind of annoying and impedes progress - Constriction This would of course create an abstraction layer that constricts the driver developer's ability to do low level complex operations for any portable binary driver A Linux specific binary driver format might be more useful, but wouldn't potentially allow for sharing the drivers across operating systems [1] http://projectudi.sourceforge.net/about.php - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMIK8hDd4aOud5P8RAo+EAJwIF7zEmiyxKzRJJ037TQ2FhYG5bACffTBX JLhXPcidbQbf18LyTmjHgh0= =gbyB -END PGP SIGNATURE- - 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/
Re: binary drivers and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg KH wrote: > On Thu, Mar 10, 2005 at 11:28:39AM -0500, John Richard Moser wrote: > >>I've been looking at the UDI project[1] and thinking about binary >>drivers and the like, and wondering what most peoples' take on these are >>and what impact that UDI support would have on the kernel's development. > > > Please, the UDI stuff has been proven to be broken and wrong. If you > want to work on it, feel free to do so, just don't expect for anyone to > accept the UDI layer into the kernel mainline. > 1. What's broken about it 2. Is it possible to fix it I require information or else I can't assess things. > What's that phrase about people forgetting history are doomed... > > greg k-h > - > 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/ > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMIGqhDd4aOud5P8RAl+PAJ4ndKTmqyRRc+qaJjPK62HBABb0rgCgjCTR 8kQ9MOOdZiH3FUsNG1Hoe3E= =NIcs -END PGP SIGNATURE- - 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/
Re: binary drivers and development
On Thu, Mar 10, 2005 at 11:28:39AM -0500, John Richard Moser wrote: > I've been looking at the UDI project[1] and thinking about binary > drivers and the like, and wondering what most peoples' take on these are > and what impact that UDI support would have on the kernel's development. UDI is already dead. You just haven't noticed. And just like with dead people it's death also had a cause :-) Ralf - 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/
Re: binary drivers and development
On Thu, Mar 10, 2005 at 11:28:39AM -0500, John Richard Moser wrote: > I've been looking at the UDI project[1] and thinking about binary > drivers and the like, and wondering what most peoples' take on these are > and what impact that UDI support would have on the kernel's development. Please, the UDI stuff has been proven to be broken and wrong. If you want to work on it, feel free to do so, just don't expect for anyone to accept the UDI layer into the kernel mainline. What's that phrase about people forgetting history are doomed... greg k-h - 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/