In retrospect, that is probably the way it should be. I had a colleague
telling me that I could compile my device driver with LiS primitives and
thus ship one driver module and not have to worry about whether the system
was SMP or UP--by letting the LiS layer take care of that. A nice idea, but
not practical for LiS to take the burden.
I've worked around the issue using all the normal kernel internals, and I'll
just ship both a UP and an SMP driver--no biggy.
Thanks,
Brendan
-----Original Message-----
From: Dave Grothe [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 19, 2001 1:26 PM
To: Miller, Brendan; '[EMAIL PROTECTED]'
Subject: Re: [Linux-streams] osif.h and port io?
Dave Grothe wrote:
> LiS stands for Linux STREAMS. As such it only attempts to provide kernel
> interface buffering for services needed by STREAMS drivers. These
services do
> not include copy_from/to_user.
>
> The port I/O routines would be good to add, though.
For Intel architecture the inb, inw, etc functions seem to be compiler
built-ins.
They are not defined by any subroutine or macro in the kernel source.
Other,
non-Intel, architectures have macros for them.
For now I think that I will not try to provide an LiS "buffer" for these
functions.
-- Dave
> "Miller, Brendan" wrote:
>
> > I have a simple port io device driver that I had previously written
using
> > standard kernel intrinsics such as inb, outb, copy_from_user,
copy_to_user,
> > etc. I read that using LiS, it was possible to build your driver once
> > against LiS, and only have to recompile LiS for the specific kernel that
was
> > being used. This way, our device driver would use a "kernel API
buffering"
> > and only LiS would have to be compiled with actual kernel source.
> >
> > Am I understanding this correctly? I thought I could use osif.h to
provide
> > most of the kernel functions I needed. The LiS PCI layer is pretty well
> > designed. What about ISA port IO? Things like inb, outb, copy_to_user,
> > copy_from_user, etc. It seems that the LiS headers are not complete for
> > _every_ type of device driver. Incidentally, my driver is not a streams
> > driver. It only provides register access between user applications and
our
> > hardware.
> >
> > Brendan Miller
> >
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
