Date: Tue, 27 Feb 2001 21:34:50 -0800 From: Julian Elischer <julian@elischer.org> To: Kostas Magoutis <magoutis@eecs.harvard.edu> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Logical device instances Message-ID: <3A9C8DFA.ABC44BA1@elischer.org> References: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> <3A9C7C27.D29A06A1@elischer.org> <200102280457.f1S4vYQ19924@wally.eecs.harvard.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostas Magoutis wrote:
>
> The networking protocol in my case has to be in user space (this is
> not the usual kind of networking card, it is used to DMA directly to
> and from user space). So, sockets in their present form won't work
> for me as they can't be used to multiplex the device without an
> intermediate IP protocol.
Neither of these two statements is actually true.
When I was working for TRW we used a small kernel protocol
to DMA directly 'from the wire' to a memory pool that was mmapped into the
userspace. It requires a co-operating network driver, but then you must
have that anyhow no matter what you are doing..
we had three drivers:
1/ network drivers that knew how to DMA packets to/from the special pool.
2/ A pseudo device that was used by user processes to mmap he pool
and to free buffers when they were finished with them (via ioctls)
3/ A modified disk driver that also knew how to directly access the memory pool.
Packets were sent out by writing the data from disk to the pool via DMA.
The process got a cookie that represented those buffers.
It then sent that cookie, plus a packet header to the network driver,
which transmitted the header, followed by the buffers. We used 15.5KB payload..
(to allow up to 512 bytes of header).
On receivce, you got the header from the socket, with a cookie (rcvmesg(2))
You could convert the cookie into buffer offsets with an ioctl, or just pass it
on to the disk driver if you wanted to write it to disk without ever looking
at it.
Obviously there was more to it than that but thats the short version..
>
> From: Julian Elischer <julian@elischer.org>
>
> device drivers for networking don't use the
> open/close/read/write interface.
> they use sockets, so that different processs open differnt sockets
> which are multiplexed onto the device using a protocol.
>
> --
> __--_|\ Julian Elischer
> / \ julian@elischer.org
> ( OZ ) World tour 2000-2001
> ---> X_.---._/
> v
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
>
> Kostas Magoutis wrote:
> >
> > I am writing a device driver for a user-level networking card. User
> > level code interacts with it via open, close, mmap, and ioctl. A
> > separate logical instance of the device needs to be created each time
> > a process opens the device (as in when a file is created when a vnode
> > is opened). The device driver needs to have a way to find out on what
> > logical instance of the device a system call is performed. It seems
> > to me that at present (with either specfs or devfs), the device driver
> > has no way to find out on what opened instance of the device an
> > operation is performed. Am I missing something or the present device
> > driver interfaces just don't support such functionality?
> > Thanks,
> >
> > Kostas
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-arch" in the body of the message
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000-2001
---> X_.---._/
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A9C8DFA.ABC44BA1>