Hello,
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.

[ Post a follow-up to this message ]

On Sep 10, 1:22 pm, Saran.j.je...@gmail.com wrote:
> Hello,
>          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.

What platform are you developing a driver for?
If it is Linux http://lwn.net/Kernel/LDD3/

[ Post a follow-up to this message ]

Maxim Yegorushkin <maxim.yegorushkin@gmail.com> writes:
>On Sep 10, 1:22 pm, Saran.j.je...@gmail.com wrote: 
>
>What platform are you developing a driver for?
>If it is Linux http://lwn.net/Kernel/LDD3/
>

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

[ Post a follow-up to this message ]

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.

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

[ Post a follow-up to this message ]

On Mon, 10 Sep 2007 16:08:16 -0600 Chris Friesen <cbf123@mail.usask.ca> wrote:
> Scott Lurndal 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.

I'm not saying it's necessarily a bad thing, just calling a spade a spade.

-frank

[ Post a follow-up to this message ]

Frank Cusack wrote:
> On Mon, 10 Sep 2007 16:08:16 -0600 Chris Friesen <cbf123@mail.usask.ca> wrote:[/vb
col]
[vbcol=seagreen] 
[vbcol=seagreen]
> 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

[ Post a follow-up to this message ]

On Tue, 11 Sep 2007 08:42:25 -0600 Chris Friesen <cbf123@mail.usask.ca> wrote:
> Frank Cusack wrote: 
> 
> 
>
> 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

[ Post a follow-up to this message ]

Chris Friesen <cbf123@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.

>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.

[ Post a follow-up to this message ]

On 11 Sep, 16:58, Casper H.S. Dik <Casper....@Sun.COM> wrote:
> Chris Friesen <cbf...@mail.usask.ca> writes: 
>
> Only if you're not trying.  The Solaris DDI/DDK interface has
> evolved over many releases of Solaris while remaining compatible
> across releases.
> 
>
> If you properly design the interfacs, then there is no need to do so.
>
> Casper
> --

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

[ Post a follow-up to this message ]

On Tue, 11 Sep 2007 10:22:32 -0700 Bahadir <Bilgehan.Balban@gmail.com> wrote:
> 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

[ Post a follow-up to this message ]