-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
I know the immediate first reactions are probably "Portable drivers are
slow" and "We don't support closed source crap." I think benchmarks are
needed, and closed drivers can always be replaced by rewritten open
ones. Really critical drivers that need the extra few microseconds can
always be low-level instead of abstracted.
The major considerations I come across mainly involve development focus
and kernel tree size. UDI drivers would be separated from the kernel,
so their development would be focused; a driver fix would not warrent a
2.6, 2.4, and 2.2 patch, plus backports in 100 distributions (which
don't concern the LKML). They'd also be in their own tarball, so the
kernel tree size would be a lot smaller if most drivers were UDI, though
by how much I'm not sure.
I'm aware that drivers would have to be loaded to the kernel like this,
being separated. Aside from having the kernel build eat drivers from
some /lib/modules/udi/ directory, grub has a "module" command that can
load multiple modules. If the kernel used that to load drivers (does it
now?), an initrd wouldn't be needed; a very straightforward bootloader
configuration would come in its place.
There is a 2.4 UDI reference model out with SCSI and NIC driver support.
Perhaps some experimentation with these would be interesting, since the
disk and the network are performance focuses. I don't think the UDI
reference model is ready quite yet for mainline, but it's ready for some
cross-examination by unbiased kernel developers.
[1] http://projectudi.sourceforge.net/
- --
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
iD8DBQFCMHW2hDd4aOud5P8RAnhSAJ9+8VdgR6EX0JwjUpysXsTMRl1ewwCeOWJR
g6mNs6NuEltgNS6qtVat5Mo=
=DrWO
-----END PGP SIGNATURE-----
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
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
-----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-----
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
-----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-----
-----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-----
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...
-----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-----
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
-----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 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
iD8DBQFCML9fhDd4aOud5P8RAglXAJ9hTu5jVZcZ/LLFFw41bjO73+ShhwCfUlma
iPcrJXwKP0ZfQ8jCsVhxhSQ=
=CknT
-----END PGP SIGNATURE-----
>>>>> "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
-----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-----
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
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
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.
Le jeudi 10 mars 2005 ? 11:28 -0500, John Richard Moser a ?crit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
[...]
Eh, nice troll ! You made a handful people react :)
Maybe there should be an explicit FAQ entry on what's the take on binary
modules.
Xav
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'
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]
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
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.
-----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-----
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
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