Open kernel parts

[osdog]

I totally agree with you in theory. But in practice we all prefer hacking on code rather than writing documentation. So what happens is quite natural...

I know ... but at the same time we all love well documented code don't we? Quite a double standard, which admittedly I'm also guilty of.

Also, re "some effort": Have you ever tried porting a Linux driver?

I've never ported a driver 1:1. But I've used Linux, *BSD or eCos numerous times as reference implementations to figure out how a specific hardware component needs to be interfaced with so it behaves the way I want. Also in that regard the GPL isn't a problem either, unless you are sticking too close to the GPL'd implementation.
EDIT: Oh my god that sounds so much like justifying plagiarisms "if you just change it enough so no one will know". I hope everyone understands that this is not what I'm trying to say!

Let me guess: Your OS doesn't have more than a handful of drivers yet. Because soon you'd realise that drivers are not where you can be creative and where your OS could try doing things differently. Drivers are just stupid boring work.

Yes I only have a handful of drivers (for the hardware that I use). Maybe I haven't reached the point where drivers are just stupid boring work yet or it is because I don't really consider drivers to be "part" of the OS as much as applications are. I rather consider the interface (driver API) the important part and with a standardized interface you "give away" a big part of your OS. Not saying that is bad, I mean there are things in an OS that people just expect - terminal (with ls, cd), files, BSD sockets, C library, POSIX functionality, a windowed environment (if the OS should have a GUI) - so in a way everyone is already letting "someone else" determine how their OS should be structured.
Also in my book once you hit the "mass" market and need a vast number of drivers you are out of the hobby environment anyway.
Lastly if my goal was supporting as many platforms are possible of course I would give up total control of the device driver interface structure so I could just use available drivers.

Sharing code with other projects for boring standard parts is a good thing and an important reason for the strength of open source. (Which is also why I recommended using an existing interface for the drivers, seeing that he's not really doing anything different from CDI here.)

Yes not scattering man power over a dozen different projects that all basically do the same thing is a good thing but as much as we love to hack on code than write documentation we also love hacking on our own projects rather than someone else's .

[Kazinsal]

I think a problem with a standardized driver interface is that it will appeal to those of us with a mature kernel, and none of us with a mature kernel want to retool all our drivers for this interface, meaning that we never end up implementing it because it's too much short-term work for little short-term gain and most likely little long-term gain.

[Kevin]

I've never ported a driver 1:1. But I've used Linux, *BSD or eCos numerous times as reference implementations to figure out how a specific hardware component needs to be interfaced with so it behaves the way I want.

This is a big difference.

Also in my book once you hit the "mass" market and need a vast number of drivers you are out of the hobby environment anyway.

If you hit the "mass market", you're probably not the typical hobby OS any more that we're talking about. Ignore these OSes. It's enough if you're working on an OS with two or three other people and maybe not everyone has only one test box. Chances are that you have five or more different network cards to support, a few sound chips and USB host controllers, and with graphics you won't even start because it's too much effort (that is, you use VESA, the standardised interface over which you have no control and which doesn't use most of your hardware's capabilities). All that with a very small group of developers.

Supporting the first few machines is the hardest, after that your chances are relatively good to hit a device that you already have a driver for. But "few" is definitely somewhat larger than one here.

Yes not scattering man power over a dozen different projects that all basically do the same thing is a good thing but as much as we love to hack on code than write documentation we also love hacking on our own projects rather than someone else's .

True to some degree. But then I hate writing boring code enough that I rather take PDCLib and send my patches there than doing everything from scratch.

I think a problem with a standardized driver interface is that it will appeal to those of us with a mature kernel, and none of us with a mature kernel want to retool all our drivers for this interface, meaning that we never end up implementing it because it's too much short-term work for little short-term gain and most likely little long-term gain.

If you already have a lot of drivers and covered everything that is available with the standardised interface, the short-term gain may be quite small indeed. I'm not sure if the average OS here has all of them. I just know that I got some drivers this way without having to implement them all myself, and for me that's already sufficient as a justification.