public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Device driver implementation questions
@ 2007-06-15  1:21 Mike Sweeney
  2007-06-15  8:43 ` [ECOS] " Grant Edwards
  0 siblings, 1 reply; 3+ messages in thread
From: Mike Sweeney @ 2007-06-15  1:21 UTC (permalink / raw)
  To: ecos-discuss

I am finding the way device drivers are implemented in eCos to be
slightly confusing so was looking for some help. The main source of my
confusion is the need for some sort of interface under the io package
and then another part of the driver in the devs package. I have looked
at examples like the serial driver and understand how it works in that
context, but am having trouble seeing the bigger picture. Should
drivers for all types of devices follow this split implementation
design? Furthermore, can someone provide me an analogy between the
eCos driver model and Linux, for example? I don't see this two layer
method in Linux so am hoping someone can clarify this.

Thanks.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [ECOS]  Re: Device driver implementation questions
  2007-06-15  1:21 [ECOS] Device driver implementation questions Mike Sweeney
@ 2007-06-15  8:43 ` Grant Edwards
  2007-06-15  9:43   ` Mike Sweeney
  0 siblings, 1 reply; 3+ messages in thread
From: Grant Edwards @ 2007-06-15  8:43 UTC (permalink / raw)
  To: ecos-discuss

On 2007-06-14, Mike Sweeney <msweeney77@gmail.com> wrote:

> I am finding the way device drivers are implemented in eCos to be
> slightly confusing so was looking for some help. The main source of my
> confusion is the need for some sort of interface under the io package
> and then another part of the driver in the devs package. I have looked
> at examples like the serial driver and understand how it works in that
> context, but am having trouble seeing the bigger picture. Should
> drivers for all types of devices follow this split implementation
> design? Furthermore, can someone provide me an analogy between the
> eCos driver model and Linux, for example? I don't see this two layer
> method in Linux so am hoping someone can clarify this.

Linux has almost the exact same two layer method for many
drivers:

  Serial drivers: There is a line-discipline layer which
  provides the application with open/close/read/write calls.
  That corresponds to the "io" stuff in eCos. The
  line-discipline layer then calls lower-level
  hardware-specific drivers for different sorts of serial
  ports.  That corresponds to the "dev" stuff in eCos.

  SCSI drivers: Pretty much the same -- there's a generic layer
  that provides an API to the user and then a lower layer that
  talks to individual SCSI controllers (or other hardware).

There are probably other examples (VFS on top of the individual
filesystem modules, 80211 on top of various card drivers).  

-- 
Grant Edwards                   grante             Yow! FUN is never having to
                                  at               say you're SUSHI!!
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Re: Device driver implementation questions
  2007-06-15  8:43 ` [ECOS] " Grant Edwards
@ 2007-06-15  9:43   ` Mike Sweeney
  0 siblings, 0 replies; 3+ messages in thread
From: Mike Sweeney @ 2007-06-15  9:43 UTC (permalink / raw)
  To: ecos-discuss

On 6/14/07, Grant Edwards <grante@visi.com> wrote:
> On 2007-06-14, Mike Sweeney <msweeney77@gmail.com> wrote:
>
> > I am finding the way device drivers are implemented in eCos to be
> > slightly confusing so was looking for some help. The main source of my
> > confusion is the need for some sort of interface under the io package
> > and then another part of the driver in the devs package. I have looked
> > at examples like the serial driver and understand how it works in that
> > context, but am having trouble seeing the bigger picture. Should
> > drivers for all types of devices follow this split implementation
> > design? Furthermore, can someone provide me an analogy between the
> > eCos driver model and Linux, for example? I don't see this two layer
> > method in Linux so am hoping someone can clarify this.
>
> Linux has almost the exact same two layer method for many
> drivers:
>
>   Serial drivers: There is a line-discipline layer which
>   provides the application with open/close/read/write calls.
>   That corresponds to the "io" stuff in eCos. The
>   line-discipline layer then calls lower-level
>   hardware-specific drivers for different sorts of serial
>   ports.  That corresponds to the "dev" stuff in eCos.
>
>   SCSI drivers: Pretty much the same -- there's a generic layer
>   that provides an API to the user and then a lower layer that
>   talks to individual SCSI controllers (or other hardware).
>
> There are probably other examples (VFS on top of the individual
> filesystem modules, 80211 on top of various card drivers).
>
> --
> Grant Edwards                   grante             Yow! FUN is never having to
>                                   at               say you're SUSHI!!
>                                visi.com

Thanks for the information, that clarifies things for me.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-06-15  1:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-15  1:21 [ECOS] Device driver implementation questions Mike Sweeney
2007-06-15  8:43 ` [ECOS] " Grant Edwards
2007-06-15  9:43   ` Mike Sweeney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).