-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here's a silly thought I had a while ago. Linux has no static ABI for
device drivers, I think the general argument was between "it's slower"
and "different hardware will have different requirements." Putting
aside design difficulties, I've come up with an example case of a useful
hardware driver ABI.
As kernel development goes on, some infrastructure changes require
drivers to be updated. Eventually some drivers become buggy and
ill-maintained, even when they used to be legitimately working ones; and
then developers have to take some of their time to fix them, or eject
them from the tree.
(I can't think of any specific cases where a driver has actually
become buggy enough that it became a notable hazard. OSS eventually was
deprecated and pulled out of the tree because its architecture was old
and it wasn't worth keeping since we have ALSA now.)
The drivers have to be shipped in the main tree as well, and the kernel
tarballs are getting bigger. 2.6.14 was in a 37M .tar.bz2; .15 was in a
38M; .16 and .17 in a 39M; .18 is in a 40M tarball. The size keeps
piling up, that's more and more code that's got to be maintained and
shipped.
Writing Linux into a microkernel isn't going to happen. Linus isn't hot
on the idea; and besides, what would the developers DO with that kind of
disruption? Tons of projects would drop off because basement coders
can't all rewrite their code for a new architecture (hey why not port
your new Linux memory management patch to FreeBSD while you're at it?).
So the only other way to isolate parts of the kernel off the main tree
is, obviously, by making a way to move drivers out of it.
This brings up a few potential questions:
- Will this eventually be necessary to an absolute? Will 100M
tarballs and hundreds of thousands of drivers be unmanageable in a
tight, ABI-unstable monolith 10 years from now?
- Would it ACTUALLY be worthwhile, given such a scenario, to expel
drivers out of the tree to glue on by a static, somewhat slower but
workable ABI so nobody has to touch the code ever?
- Is there actually a benefit -now- to ejecting drivers from the tree,
or are the developers pretty much comfortable polishing the stuff
nobody normally touches here and there?
Just curious.
- --
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRTBXCQs1xW0HCTEFAQKQyA/+Psr/NMmyrGGKBxeRw4AchHS2danZlS87
Mps20R8tm9CJMWUuPw0xZneBWz5kzG9MPJ4HvcAB4BZK1mp7a/ojFePIu1ZMW2qr
Xqn+yqk4vBr3ayh0Z8OFicxdDoJ/i47ON1h3QYfi3X9N/aLG/nMgFVbXJZ6CnImt
HQqj2YHGhvzu2CEQqYh3BzVOZkBJJ7AMgmIVUzajIrbGtR2/0XTyLvGfPYr9hzi0
N1YS+Rrgo7UoHU54qOjXoFWrrmvRc27vZydPTyU7DPDnruNNljS9QnfuT1XQbzyq
wM1+nFr6gHKPHI3MiZ3IktQnDSy0FQV08TRrTkFq88kE5zT79NkZIH7L4rQtN/VN
+dUV1JIQ1FvEnCATUpYueyb01BOIFK1xMIS2UMOFaghF09GmWhd+eIk80TT8PVaK
PvjEJ8FqQjSBqBPKzHVD8e1q86pfjZmLrQH+djLkkmfGXnqKG3BUWBfX+h4pQii5
iEpo0eznfxCvejvnyrWgl2jsKYW0dff7R4MQoPP99MgHXK7/hV4jmJTjNsh5z13j
vy+na5HR99IsGzBfwDgJIu6UPxq0Zf6JlP33dzeFgYyc3zAlAJMrrAZYDe+3xJsA
LJ7kNAdv51UhPQwAW45q+fWsn4iVOe9RgyNL5fBl4D8TkYdaHdsx2UVEoY54QEAZ
1O4ALzjdnVY=
=owQK
-----END PGP SIGNATURE-----
On Fri, Oct 13, 2006 at 11:18:35PM -0400, John Richard Moser wrote:
>
> Here's a silly thought I had a while ago. Linux has no static ABI for
> device drivers, I think the general argument was between "it's slower"
> and "different hardware will have different requirements." Putting
> aside design difficulties, I've come up with an example case of a useful
> hardware driver ABI.
>
> As kernel development goes on, some infrastructure changes require
> drivers to be updated. Eventually some drivers become buggy and
> ill-maintained, even when they used to be legitimately working ones; and
> then developers have to take some of their time to fix them, or eject
> them from the tree.
The rule is simple:
If you break an in-kernel API, you have to fix all in-kernel users.
No matter how ill-maintained a driver is, that works quite good.
>...
> This brings up a few potential questions:
>
> - Will this eventually be necessary to an absolute? Will 100M
> tarballs and hundreds of thousands of drivers be unmanageable in a
> tight, ABI-unstable monolith 10 years from now?
"hundreds of thousands of drivers" won't happen during my lifetime.
If the kernel size only doubles to 100 MB that's no problem.
> - Would it ACTUALLY be worthwhile, given such a scenario, to expel
> drivers out of the tree to glue on by a static, somewhat slower but
> workable ABI so nobody has to touch the code ever?
Documentation/stable_api_nonsense.txt describes why this is nonsense.
And if you anyway don't want to change the kernel API, it doesn't make
any difference for you whether the drives are shipped with the kernel.
And external drivers with various interdependencies and dependencies
would be an insane maintenance nightmare.
> - Is there actually a benefit -now- to ejecting drivers from the tree,
> or are the developers pretty much comfortable polishing the stuff
> nobody normally touches here and there?
The goal is to get drivers into the kernel and shipping a complete
kernel with all drivers.
> Just curious.
This point comes up every few months on this list, so instead of
starting the same old disussion on this topic please read the old
discussions in the list archives.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
>> ...
>> This brings up a few potential questions:
>>
>> - Will this eventually be necessary to an absolute? Will 100M
>> tarballs and hundreds of thousands of drivers be unmanageable in a
>> tight, ABI-unstable monolith 10 years from now?
>
> "hundreds of thousands of drivers" won't happen during my lifetime.
>
> If the kernel size only doubles to 100 MB that's no problem.
>
>> - Would it ACTUALLY be worthwhile, given such a scenario, to expel
>> drivers out of the tree to glue on by a static, somewhat slower but
>> workable ABI so nobody has to touch the code ever?
>
> Documentation/stable_api_nonsense.txt describes why this is nonsense.
>
stable api is even nonsense for Windows, which tries to have a stable
api for drivers. For example, manufacturers are having to write Vista
specific drivers, because their old Windows XP drivers don't work on
Vista. E.g. Creative sound cards.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adrian Bunk wrote:
> On Fri, Oct 13, 2006 at 11:18:35PM -0400, John Richard Moser wrote:
>> Here's a silly thought I had a while ago. Linux has no static ABI for
>> device drivers, I think the general argument was between "it's slower"
>> and "different hardware will have different requirements." Putting
>> aside design difficulties, I've come up with an example case of a useful
>> hardware driver ABI.
>>
>> As kernel development goes on, some infrastructure changes require
>> drivers to be updated. Eventually some drivers become buggy and
>> ill-maintained, even when they used to be legitimately working ones; and
>> then developers have to take some of their time to fix them, or eject
>> them from the tree.
>
> The rule is simple:
> If you break an in-kernel API, you have to fix all in-kernel users.
>
> No matter how ill-maintained a driver is, that works quite good.
>
Nods. I hope that keeps working then.
>> ...
>> This brings up a few potential questions:
>>
>> - Will this eventually be necessary to an absolute? Will 100M
>> tarballs and hundreds of thousands of drivers be unmanageable in a
>> tight, ABI-unstable monolith 10 years from now?
>
> "hundreds of thousands of drivers" won't happen during my lifetime.
>
> If the kernel size only doubles to 100 MB that's no problem.
>
The below is purely informative. I would like to wait until around
2.6.30 and redo the math, because I am not certain of the growth. I
believe it would be statistically more sound to have a wider sample base
to calculate the regression from, especially with the wide variance in
growth between kernel versions.
I've mapped the growth of the .tar.bz2 archives in kilobytes since
2.6.0, they show an erratic pattern but a strong overall linear growth
pattern. This means the actual size of the kernel is polynomial and
integrates crudely to:
18.59x^2+133.1x+32600
For x == minor (i.e. 2.6.0 == 0; 2.6.18 == 18). This produces a level
of error; however, I've graphed the error and it seems to be off by no
more than 400k ever and show a horizontal trend (i.e. overall accurate);
however I'll have to apply the same prediction to future kernel versions
to get a good picture.
The point is that compressed kernel source tree size is growing on the
order of a second degree polynomial. I have not done measurements on
the uncompressed tree size because I'd have to download and decompress
every version; but I imagine it correlates, due to the nature of
compression.
My math predicts that 2.6.57 (+39) will be 100M (in approximately 7
years if you assume 1 kernel release every 2 months); 2.6.92 (+35) will
breech 200M; 2.6.117 (+25) will breech 300M; and 2.6.138 (+21)) will
breech 400M. That should suffice for predictions over the next 20 years
based on this crude model.
I would like to wait for more data and perform a better analysis in 2
years; although I would be interested now in finding a way to get the
full kernel source tree size in bytes without actually downloading and
unpacking all the tarballs. Is there a list somewhere I can use?
>> - Would it ACTUALLY be worthwhile, given such a scenario, to expel
>> drivers out of the tree to glue on by a static, somewhat slower but
>> workable ABI so nobody has to touch the code ever?
>
> Documentation/stable_api_nonsense.txt describes why this is nonsense.
>
> And if you anyway don't want to change the kernel API, it doesn't make
> any difference for you whether the drives are shipped with the kernel.
>
> And external drivers with various interdependencies and dependencies
> would be an insane maintenance nightmare.
>
This is probably true.
>> - Is there actually a benefit -now- to ejecting drivers from the tree,
>> or are the developers pretty much comfortable polishing the stuff
>> nobody normally touches here and there?
>
> The goal is to get drivers into the kernel and shipping a complete
> kernel with all drivers.
>
>> Just curious.
>
> This point comes up every few months on this list, so instead of
> starting the same old disussion on this topic please read the old
> discussions in the list archives.
>
> cu
> Adrian
>
- --
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRTD8jQs1xW0HCTEFAQLwyBAAkT1TO+paC0H2LJpVfViej0WnL6s4BRr6
uRkha7zqLqEmtfGtUONvlbYIUkci+ItjDPdl4gNLXiiBwFoV4fylKHDeKqykub8v
qZg+4tiRC/5DSsSi1v0RTOTmmzcLJg8npYmCWSLsCh8ZN83WlJmJ8moTdKvLJWsF
qQ2YWqKqdr7kW6//vTGsgHCAh2l0TQtX7UZop5XU7JB1nwbEfuaLmuDrKD9KRw3j
s0zo8fEed71Usl6FRyqUcsl50lauc/DfCGazMgzcyaTXvTwXbF+GLb1a+BUwnk7L
ensx15GfsZwYQT/pupw2jlp7XPHqZ8/1Z55UO+faxkWugOC361dV93dSGUVzQ4dR
huLZGB7Abwd3R7Gbyk51VwZPys+PWfQUkG4oujW+6UQNTMjwvBadj+OuONcvq819
QYYJrCSFq40aeBWgsE4OF4px+ngOR4FMPdM7R6NdwD5jQ+deAbtTN4+ebWWnUUrx
NPUvt4fJGv3eWTGEGz+cAnZqUtoPSna3n2LZKqN03pIO1agTWKqb5Z6q4Lx+DeWl
9kIEnaDC2wepPSKh1p7ZQbnungiSsNcB6U7ngQCTPtnNMAfwSp6rA5PUtb2DJt03
0Du4sY9cOYWtB+2nyTN8eDeKfsAjb6mUueZTdHNt0Lx03HengpMU1m8/J4CeNVMb
0fifJoDorhw=
=6PWi
-----END PGP SIGNATURE-----
John Richard Moser <[email protected]> wrote:
[...]
> I've mapped the growth of the .tar.bz2 archives in kilobytes since
> 2.6.0, they show an erratic pattern but a strong overall linear growth
> pattern. This means the actual size of the kernel is polynomial and
> integrates crudely to:
>
> 18.59x^2+133.1x+32600
>
> For x == minor (i.e. 2.6.0 == 0; 2.6.18 == 18). This produces a level
> of error; however, I've graphed the error and it seems to be off by no
> more than 400k ever and show a horizontal trend (i.e. overall accurate);
> however I'll have to apply the same prediction to future kernel versions
> to get a good picture.
Hum... perhaps going against time (not minor) is better?
You could also include the whole 2.5.x set (at least since git became
common) for a larger series...
[...]
> My math predicts that 2.6.57 (+39) will be 100M (in approximately 7
> years if you assume 1 kernel release every 2 months); 2.6.92 (+35) will
> breech 200M; 2.6.117 (+25) will breech 300M; and 2.6.138 (+21)) will
> breech 400M. That should suffice for predictions over the next 20 years
> based on this crude model.
I'd trust your curve for, say, 5 minors. Not more. The quadratic term is
rather hard to justify in any case... linear growth (== new drivers at a
(roughly) constant rate, a (roughly) constant number of people actively
working on the kernel with constant productivity, ...) I give you easily.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Horst H. von Brand wrote:
> John Richard Moser <[email protected]> wrote:
>
> [...]
>
>> I've mapped the growth of the .tar.bz2 archives in kilobytes since
>> 2.6.0, they show an erratic pattern but a strong overall linear growth
>> pattern. This means the actual size of the kernel is polynomial and
>> integrates crudely to:
>>
>> 18.59x^2+133.1x+32600
>>
>> For x == minor (i.e. 2.6.0 == 0; 2.6.18 == 18). This produces a level
>> of error; however, I've graphed the error and it seems to be off by no
>> more than 400k ever and show a horizontal trend (i.e. overall accurate);
>> however I'll have to apply the same prediction to future kernel versions
>> to get a good picture.
>
> Hum... perhaps going against time (not minor) is better?
>
I think revisions have an average time between them that follows a
general linear trend. {1 4 3 1 0 2 2 3} is a general linear trend; a
line between these points best dividing half above and half below is
horizontal. *The assertion that revision numbers are linearly
correlated to time is a conjecture; I have not verified this
mathematically.*
> You could also include the whole 2.5.x set (at least since git became
> common) for a larger series...
Perhaps, but that was a heavy development period and I want to avoid
lurking variables; otherwise I'd have included 2.4's whole series too.
I know this is a lost cause in 2.6, what with things like devfs or OSS
dropping and ALSR getting merged in at random times....
>
> [...]
>
>> My math predicts that 2.6.57 (+39) will be 100M (in approximately 7
>> years if you assume 1 kernel release every 2 months); 2.6.92 (+35) will
>> breech 200M; 2.6.117 (+25) will breech 300M; and 2.6.138 (+21)) will
>> breech 400M. That should suffice for predictions over the next 20 years
>> based on this crude model.
>
> I'd trust your curve for, say, 5 minors. Not more. The quadratic term is
> rather hard to justify in any case... linear growth (== new drivers at a
> (roughly) constant rate, a (roughly) constant number of people actively
> working on the kernel with constant productivity, ...) I give you easily.
(ax^2 + bx + c)d/dx == 2ax + b
I didn't eye the curve as quadratic; I eyed it as a gentle curve. I
took the differences and looked for a trend specifically because I know
a linear growth trend (polynomial degree 1) indicates a quadratic trend
(polynomial degree 2).
As I said, I don't have enough samples. I only used 16 of the 19
samples I have to generate the function above; I would like upwards of
30 before claiming any useful trend.
- --
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRTFDnws1xW0HCTEFAQLLHA//WxyEu7Tzh/Lt6RAWL3qA1xHHm2E2WWBc
bUCq4ONuXheZ9rdQM0VHdLIdkPNvkFPtBXSugEIPCIMDSjR8+z1U+kv96Od96Gb0
TfSLMGIUnVzdhAHzwTo35vfPrQb3dIVA4j+3dgMHX0e+OEWDeHhHsAWSjgkwqhe4
OQ6SvCZVIxV2nFTJ3MkbNqITVBNmWy4cy16L3H6GiiQl/q3tg71Dochcn83ySNlc
9NCP4igLVlfjThNCK8pJtDoZX887oCFB/npSOSiwKQKciAlMooAgmDRTh55pa7D4
XD+Lilxwp/jFXbtv/9HdoETeN7kZLcVYbGfMosDvwxl5g2smzCLWEv5qvUCs3lDQ
gh4knxGF59Vupou+irI9L+1FC3irJcS92x3ITFQwwTRT3rZ5hVMPIBaxovWN2oVY
U0InH4VhLY+yWADL3BkWEi/pNQ2YxiXw5VdSDHMitBHEczOyE2emAkVTBvuGl/wP
v2iDVHJU9A1IMsN0EG+C+hpOR4kqIU/WT/aLAC3JwUKb+RTFadgRdYs6/ca++2ks
iFwA55Dd20iQ3p/uCwXMvugWAGwo+tPXHIBJy3RSnPkL4r/CaA1RwC7Gn/EDqgeA
w2jO6hYcKKX91MEFpfvqUjNx5Oq4gHf/20rLQi7kMW12LVkVDmKZe840KETSt3Wb
O8MAMIs894s=
=6G+v
-----END PGP SIGNATURE-----
On Oct 14, 2006, at 10:04 AM, John Richard Moser wrote:
> My math predicts that 2.6.57 (+39) will be 100M (in approximately 7
> years if you assume 1 kernel release every 2 months); 2.6.92 (+35)
> will
> breech 200M; 2.6.117 (+25) will breech 300M; and 2.6.138 (+21)) will
> breech 400M. That should suffice for predictions over the next 20
> years
> based on this crude model.
>
Who knows. By that time, CPU caches may be that size. And hopefully
tools are developed to an extent that they can automate cleanup.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevin K wrote:
>
> On Oct 14, 2006, at 10:04 AM, John Richard Moser wrote:
>> My math predicts that 2.6.57 (+39) will be 100M (in approximately 7
>> years if you assume 1 kernel release every 2 months); 2.6.92 (+35) will
>> breech 200M; 2.6.117 (+25) will breech 300M; and 2.6.138 (+21)) will
>> breech 400M. That should suffice for predictions over the next 20 years
>> based on this crude model.
>>
>
> Who knows. By that time, CPU caches may be that size. And hopefully
> tools are developed to an extent that they can automate cleanup.
>
Yeah, a static code coverage analyzer or some sort of code-reducer would
be nice; these are in general pipe dreams but eh. Also these are
compressed bzip2 tarball sizes, not compiled kernel sizes or source tree
sizes. I would imagine a 100MB bzip2 would turn into something quite
large; the major issue is the amount of work it takes to maintain
something like that.
I am slowly forming the prediction that monolithic kernels won't survive
(Net/Open/FreeBSD, Linux) and only microkernels or so-called
"nanokernels" (or the exokernel ...) will be maintainable EVENTUALLY;
however I don't have sufficient data, as one would have to illustrate a
maintenance advantage in those models to complete that prediction and I
lack understanding to do such. Besides, there's no good data on the
upper bound of what is maintainable; it's somewhere below the size of
the universe, that's about all I can give you.
- --
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRTFZkQs1xW0HCTEFAQJs2A//YSjtTW8JR0n+Rz4XrBsib4O1Qgo1CGmd
ybbIQxE1eO8OG/p7uaJuHVaot1CrG6i3+D/hXp5rVAo4hDtnABLCymLtpjGDMM2o
l8tjY2c7qZ2cBwe356xM21eIPXvO0aNy21Etj5mfohtI4OAn0YTdL+tIwDnH/FOH
qLEFB8yXo5ebRRJJByVdnSJzYxzegszwsJk4JchBEuOxHdoA+sX+V/eUCZIUeJ/t
QsKsk5P/ETnPvfEpq2T53wXHba14r+AdbIoxT1q9mKMSZP7KWkn7u5v7J4MGI7JL
/5wWuk9ezjJn9b8ucu4YAJnf1Uojdo06Q6yqIVlB0pg7eGXdJv73lWXet5A4nUoA
VSDHIqJSy7cPkK4JqghbqJO9R0dca8INAhRkkLvj2zEynw6aG2jo90ZGvDzANPzU
QvGbck2uatY88V/Cvyi0XnkdU/cEPjPnx0OC+7yWHVKTF3p/FYuOXSiruBCgmFtX
7ZCMU89ZNhNUED1nMovQQaChqcgbLQdCvaYOhLcNsIkbmt1zUCx1SeTw4+FCxKYZ
qI0YQ/5mv5NQxIdz/kFN8mu0ULxmzTFz4cK3RmELKvxPvbZA+NExV8c99Po9MLSU
obtEbr/s5g11/Vn9DLR5SuA5hSniEcENQkYMAh7JnreYwIGJ/1KS6n6z6jBGcUY6
lkDp86qR3hg=
=Ft1u
-----END PGP SIGNATURE-----
Ar Sad, 2006-10-14 am 17:44 -0400, ysgrifennodd John Richard Moser:
> Yeah, a static code coverage analyzer or some sort of code-reducer would
> be nice; these are in general pipe dreams but eh. Also these are
> compressed bzip2 tarball sizes, not compiled kernel sizes or source tree
> sizes. I would imagine a 100MB bzip2 would turn into something quite
> large; the major issue is the amount of work it takes to maintain
> something like that.
It's not actually clear that you can sensibly evaluate trends like that
or the maintainability. Take a look at the flamewar the day the kernel
tarball stopped fitting on one floppy disk (1.44MB)
Things ceasing to be maintained and exiting the kernel is a two step
process and there is a lot in the "waiting for someone to rescue it"
stage that probably has no remaining users. At some point nor far away
there is going to be a big flush of drivers when ISA bus is dropped.
Microsoft are also being very helpful. They are making it harder and
harder for people to use drivers not microsoft-signed which in turns
pushes up costs for development and as a result encourages more
standardization of driver interfaces to take place.
Alan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alan Cox wrote:
> Ar Sad, 2006-10-14 am 17:44 -0400, ysgrifennodd John Richard Moser:
>> Yeah, a static code coverage analyzer or some sort of code-reducer would
>> be nice; these are in general pipe dreams but eh. Also these are
>> compressed bzip2 tarball sizes, not compiled kernel sizes or source tree
>> sizes. I would imagine a 100MB bzip2 would turn into something quite
>> large; the major issue is the amount of work it takes to maintain
>> something like that.
>
> It's not actually clear that you can sensibly evaluate trends like that
> or the maintainability. Take a look at the flamewar the day the kernel
> tarball stopped fitting on one floppy disk (1.44MB)
>
I was using something called DOS back then I think....
> Things ceasing to be maintained and exiting the kernel is a two step
> process and there is a lot in the "waiting for someone to rescue it"
> stage that probably has no remaining users. At some point nor far away
> there is going to be a big flush of drivers when ISA bus is dropped.
>
WOW that means I'll lose networking on my other machine, which uses a
D-Link on an ISA bus to power a Pentium 200MHz with MMX technology.
> Microsoft are also being very helpful. They are making it harder and
> harder for people to use drivers not microsoft-signed which in turns
> pushes up costs for development and as a result encourages more
> standardization of driver interfaces to take place.
huh?
>
> Alan
>
>
- --
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRTF4EAs1xW0HCTEFAQK1tg/9Gbhv3XM6viYCHWj+XPfyZ4QTNdQ4EPgO
h9V3lU34PZdq65NOwIyqMPx+QeMAH3YQiyR5hyplYLzkE9/bZCe+xjLL2YTOx/C8
N0BvGTHCIgqhiTWOu1/3nE7R6sPnMUh2dgBDcHdfHFIGJfcVAVYL5XiOvJEL/85a
3pl1P3OUxVhTgCZTAGHI0NDOyt8IRMVyGy8QbInNpfLHrF14qApEK4Blx9M+SKou
QRGIgjm1RusjdEHn2kIE0AWNHl3niVLfWCIies611pqiPUiwr/eztmrGzt0/XuwZ
LYBitpSsHPH16s8eIWijGev7I42aN3q+wwoKB/2BwzqHSXvpJ9W+I1Q1rsmvrOa9
7OkyrwGss4VTJawKPiyqzV00XZjhTpLqAuRePwG8zt8Usor8P6DYxl/4cHYklOH1
uH2qSCxVK2nX9V20NVvDfnpNya5aFMe7HVzWPcigASk1KJak1VneNiotX2FenwpM
i15wjBe7V8Vxj+WXa0cG1NFBUXx9jnrSu44BqeuO/rMCJ9vS0P0eHxv2Z9wD7WRn
0vC1nQ5w2FyJzaev5Nh4CprasOaZR/MoUlL5W95/jUIGxak4xr7Hhs8yi9QSd1rJ
w8rHmtz5CKH33FqYZgsaOwDQjm9MleY+O9+i+RejCneSRxBT8FjHvy6gvJ+DypSZ
t1QJ4gkK5MI=
=lsV7
-----END PGP SIGNATURE-----
On Oct 14, 2006, at 6:51 PM, John Richard Moser wrote:
>
>> Microsoft are also being very helpful. They are making it harder and
>> harder for people to use drivers not microsoft-signed which in turns
>> pushes up costs for development and as a result encourages more
>> standardization of driver interfaces to take place.
>
> huh?
>
My assumption is that vendors may make fewer gratuitious interface
changes so the hardware is more likely to work with existing, signed,
drivers. If changes aren't made, existing Linux drivers are more
likely to work with new revisions of hardware.
My experience in the past for hardware, such as USB based flash
memory readers, is that when they came out you seemed to always need
a proprietary driver, and Linux drivers needed hints for different
readers. It seems better these days, with things like USB keys
generally working in both Windows and relatively modern distributions
without much effort.llin
On Sunday 15 October 2006 02:24, Kevin K wrote:
> On Oct 14, 2006, at 6:51 PM, John Richard Moser wrote:
> >> Microsoft are also being very helpful. They are making it harder and
> >> harder for people to use drivers not microsoft-signed which in turns
> >> pushes up costs for development and as a result encourages more
> >> standardization of driver interfaces to take place.
> >
> > huh?
>
> My assumption is that vendors may make fewer gratuitious interface
> changes so the hardware is more likely to work with existing, signed,
> drivers. If changes aren't made, existing Linux drivers are more
> likely to work with new revisions of hardware.
>
> My experience in the past for hardware, such as USB based flash
> memory readers, is that when they came out you seemed to always need
> a proprietary driver, and Linux drivers needed hints for different
> readers. It seems better these days, with things like USB keys
> generally working in both Windows and relatively modern distributions
> without much effort.
Alan's talking about standards like AHCI, {U,O,E}HCI, AC'97, all standards for
silicon that make writing generic drivers possible.
I'm patiently waiting for an equivalent for wireless, or graphics (hopefully
not another VESA)..
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Ar Sad, 2006-10-14 am 19:51 -0400, ysgrifennodd John Richard Moser:
> > Microsoft are also being very helpful. They are making it harder and
> > harder for people to use drivers not microsoft-signed which in turns
> > pushes up costs for development and as a result encourages more
> > standardization of driver interfaces to take place.
>
> huh?
Every vendor of products for Microsoft Windows (which is still the
primary market for all their hardware) has to provide drivers or work
with pre-existing drivers. The harder Microsoft makes it (in financial
terms) for them to produce drivers the more incentive they have to use
the existing standards or to create new ones.
Alan
>> I've mapped the growth of the .tar.bz2 archives in kilobytes since
>> 2.6.0, they show an erratic pattern but a strong overall linear growth
>> pattern. This means the actual size of the kernel is polynomial and
>> integrates crudely to:
>>
>> 18.59x^2+133.1x+32600
>>
>> For x == minor (i.e. 2.6.0 == 0; 2.6.18 == 18). This produces a level
>> of error; however, I've graphed the error and it seems to be off by no
>> more than 400k ever and show a horizontal trend (i.e. overall accurate);
>> however I'll have to apply the same prediction to future kernel versions
>> to get a good picture.
>
>Hum... perhaps going against time (not minor) is better?
>
>You could also include the whole 2.5.x set (at least since git became
>common) for a larger series...
Time to make things clear! Many webpages that compare the sizes of
kernel evolution levels ("2.2.0 vs 2.4.0 vs 2.6.0") assume it grows
exponentially. However, if you graph it over time (as Horst suggested),
you get something that is quite linear. I took the sizes of uncompressed
tarballs, since the mirror ftp and a good decompressing opteron happens
to be connected right on the local Ethernet.
Share and enjoy:
http://img455.imageshack.us/img455/9192/kerneljg0.png
>
>[...]
>
>> My math predicts that 2.6.57 (+39) will be 100M (in approximately 7
>> years if you assume 1 kernel release every 2 months); 2.6.92 (+35) will
>> breech 200M; 2.6.117 (+25) will breech 300M; and 2.6.138 (+21)) will
>> breech 400M. That should suffice for predictions over the next 20 years
>> based on this crude model.
>
>I'd trust your curve for, say, 5 minors. Not more. The quadratic term is
>rather hard to justify in any case... linear growth (== new drivers at a
>(roughly) constant rate, a (roughly) constant number of people actively
>working on the kernel with constant productivity, ...) I give you easily.
>--
>Dr. Horst H. von Brand User #22616 counter.li.org
>Departamento de Informatica Fono: +56 32 2654431
>Universidad Tecnica Federico Santa Maria +56 32 2654239
>Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
>-
-`J'
--
On Sun, 2006-10-15 at 15:33 +0100, Alan Cox wrote:
> Ar Sad, 2006-10-14 am 19:51 -0400, ysgrifennodd John Richard Moser:
> > > Microsoft are also being very helpful. They are making it harder and
> > > harder for people to use drivers not microsoft-signed which in turns
> > > pushes up costs for development and as a result encourages more
> > > standardization of driver interfaces to take place.
> >
> > huh?
>
> Every vendor of products for Microsoft Windows (which is still the
> primary market for all their hardware) has to provide drivers or work
> with pre-existing drivers. The harder Microsoft makes it (in financial
> terms) for them to produce drivers the more incentive they have to use
> the existing standards or to create new ones.
that makes very much sense, theres just one thing i dont understand.
when there is an established standard, how can it EVER be in a companys
best interrest to develop a new product that doesent use it, and thereby
requires the development of new drivers, the distributing of those
drivers, and all that sort?
>
> Alan
>
> -
> 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/
>
On Mon, 2006-10-16 at 11:39 +0200, Kasper Sandberg wrote:
> that makes very much sense, theres just one thing i dont understand.
>
> when there is an established standard, how can it EVER be in a
> companys best interrest to develop a new product that doesent use it,
> and thereby requires the development of new drivers, the distributing
> of those drivers, and all that sort?
Easy - when they think they can provide equivalent functionality and hit
a lower price point (or make a bigger profit at the same price point) by
violating the standard.
Lee
On Mon, Oct 16, 2006 at 10:13:21AM -0400, Lee Revell wrote:
> Easy - when they think they can provide equivalent functionality and hit
> a lower price point (or make a bigger profit at the same price point) by
> violating the standard.
Or they think they can make their product using their own driver work
better and faster and offer more bling than products using the existing
driver, and they assume people will pay more for that hence justifying
the expense.
--
Len Sorensen
