If your driver is a STREAMS driver then it is intended that LiS can provide this
interface for you. The "in/out" instructions do not have differences vis a vis
SMP/UP. I have STREAMS driver code here that I can use the same binary via LiS
on any combination of 2.2/2.4 SMP/UP kernels.
-- Dave
"Miller, Brendan" wrote:
> 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
