POSIX standard for Driver development
Saran....@gmail.com
Am just started using POSIX. as far now i know that its a
standard for application level programming interfaces, i need to know
any such standard exist for driver development ,thanks for your time.
Maxim Yegorushkin
What platform are you developing a driver for?
If it is Linux http://lwn.net/Kernel/LDD3/
Scott Lurndal
That is not a standard. There is no standard for Linux kernel driver
development. Various proprietary Unix implementations do provide
documented driver frameworks (e.g. SVR4 DDK) as does windows with
the windows DDK.
For linux drivers, the LDD book pointed to above is a start, but be
aware that no interface you use today is guaranteed to be there in the
next kernel release.
scott
Chris Friesen
> For linux drivers, the LDD book pointed to above is a start, but be
> aware that no interface you use today is guaranteed to be there in the
> next kernel release.
This is by design intent. The kernel developers want to get drivers
submitted to the mainline kernel. Once they are in mainline, major API
changes will generally be done by the kernel team which reduces the
maintenance load on the driver maintainer.
On the other hand, it makes it interesting to maintain an out-of-tree
driver that tries to be compatible with many different kernel versions.
On example of a driver that does this fairly well is the e1000 driver
on sourceforge.
Chris
Frank Cusack
> Scott Lurndal wrote:
>
>> For linux drivers, the LDD book pointed to above is a start, but be
>> aware that no interface you use today is guaranteed to be there in the
>> next kernel release.
>
> This is by design intent. The kernel developers want to get drivers
> submitted to the mainline kernel. Once they are in mainline, major
> API changes will generally be done by the kernel team which reduces
> the maintenance load on the driver maintainer.
That's ridiculous. The actual reason is so that the burden of proper
design doesn't have to be incurred by the kernel team. Saying
anything else is an after-the-fact rationalization.
I'm not saying it's necessarily a bad thing, just calling a spade a spade.
-frank
Chris Friesen
> On Mon, 10 Sep 2007 16:08:16 -0600 Chris Friesen <cbf...@mail.usask.ca> wrote:
>>This is by design intent. The kernel developers want to get drivers
>>submitted to the mainline kernel. Once they are in mainline, major
>>API changes will generally be done by the kernel team which reduces
>>the maintenance load on the driver maintainer.
> That's ridiculous. The actual reason is so that the burden of proper
> design doesn't have to be incurred by the kernel team. Saying
> anything else is an after-the-fact rationalization.
The linux kernel design process is evolutionary rather than based on
up-front design (which is difficult when you don't know what the design
criteria will be in 5 years).
The fact that they are not locked in to any particular stable API for
kernel modules means that there is the possibility of modifying the API
to make it better without having to also kludge in some sort of
backwards compatibility mode.
Of course, it also makes my life painful--I work in embedded linux
development, and we tend to pick a kernel and stay with it for a couple
years. In the meantime the mainline kernel advances and changes and
when we go to upgrade to a new kernel (jumping a half-dozen kernel
versions) there are all sorts of things that have changed.
Chris
Frank Cusack
> Frank Cusack wrote:
>> On Mon, 10 Sep 2007 16:08:16 -0600 Chris Friesen <cbf...@mail.usask.ca> wrote:
>
>>>This is by design intent. The kernel developers want to get drivers
>>>submitted to the mainline kernel. Once they are in mainline, major
>>>API changes will generally be done by the kernel team which reduces
>>>the maintenance load on the driver maintainer.
>
>> That's ridiculous. The actual reason is so that the burden of proper
>> design doesn't have to be incurred by the kernel team. Saying
>> anything else is an after-the-fact rationalization.
>
> The linux kernel design process is evolutionary rather than based on
> up-front design (which is difficult when you don't know what the
> design criteria will be in 5 years).
>
> The fact that they are not locked in to any particular stable API for
> kernel modules means that there is the possibility of modifying the
> API to make it better without having to also kludge in some sort of
> backwards compatibility mode.
Yup, that's one of the reasons I said it wasn't necessarily bad.
There are others as well. But "by design" is a cop-out. I've
heard this before and I wonder if it got started by one of the
Linux folks or was it a fanboy.
> Of course, it also makes my life painful--I work in embedded linux
> development, and we tend to pick a kernel and stay with it for a
> couple years. In the meantime the mainline kernel advances and
> changes and when we go to upgrade to a new kernel (jumping a
> half-dozen kernel versions) there are all sorts of things that have
> changed.
Even though doing the major upgrades may be painful, it's better than
*constantly* chasing a moving target. You just have to take the good
with the bad I guess.
-frank
Casper H.S. Dik
>The linux kernel design process is evolutionary rather than based on
>up-front design (which is difficult when you don't know what the design
>criteria will be in 5 years).
Only if you're not trying. The Solaris DDI/DDK interface has
evolved over many releases of Solaris while remaining compatible
across releases.
>The fact that they are not locked in to any particular stable API for
>kernel modules means that there is the possibility of modifying the API
>to make it better without having to also kludge in some sort of
>backwards compatibility mode.
If you properly design the interfacs, then there is no need to do so.
>Of course, it also makes my life painful--I work in embedded linux
>development, and we tend to pick a kernel and stay with it for a couple
>years. In the meantime the mainline kernel advances and changes and
>when we go to upgrade to a new kernel (jumping a half-dozen kernel
>versions) there are all sorts of things that have changed.
So use an OS with stable interfaces, like (Open)Solaris.....
Loads 10 year old device drivers just fine :-)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Bahadir
> Chris Friesen <cbf...@mail.usask.ca> writes:
> >The linux kernel design process is evolutionary rather than based on
> >up-front design (which is difficult when you don't know what the design
> >criteria will be in 5 years).
>
> Only if you're not trying. The Solaris DDI/DDK interface has
> evolved over many releases of Solaris while remaining compatible
> across releases.
>
> >The fact that they are not locked in to any particular stable API for
> >kernel modules means that there is the possibility of modifying the API
> >to make it better without having to also kludge in some sort of
> >backwards compatibility mode.
>
> If you properly design the interfacs, then there is no need to do so.
>
> --
Clearly, the definition of *properly* is very vague, in fact *design*
and proper anticipation is contradictive in itself. How would you know
your USB stack has the right interface in advance before you design
it?
The question of whether having a whole USB stack in the kernel is
appropriate or not is another matter, of course.
Thanks,
Bahadir
Frank Cusack
> Clearly, the definition of *properly* is very vague, in fact *design*
> and proper anticipation is contradictive in itself. How would you know
> your USB stack has the right interface in advance before you design
> it?
you wouldn't, but you would know before you *implement* it. and proper
design does anticipate future enhancement.
-frank
Chris Friesen
If you haven't implemented any of the users of the stack, how do you
know the stack itself has the right API?
Assume you come up with an API that looks pretty good. So you implement
it. Then people start writing code that uses the stack, and for a while
things look okay. Then someone wants to do something strange that
wasn't originally planned for in the design, and someone else finds a
corner case that got missed, and someone else figures out a way to make
it faster but it means a minor internal API change, and maybe this other
function really doesn't need to be exported for use by modules, etc., etc.
After a couple years of this, things look a lot different.
Chris