Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Feb 2001 01:30:50 -0500 (EST)
From:      Kostas Magoutis <magoutis@eecs.harvard.edu>
To:        julian@elischer.org
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: Logical device instances
Message-ID:  <200102280630.f1S6UoW07894@wally.eecs.harvard.edu>
In-Reply-To: <3A9C8DFA.ABC44BA1@elischer.org> (message from Julian Elischer on Tue, 27 Feb 2001 21:34:50 -0800)
References:  <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> <3A9C7C27.D29A06A1@elischer.org> <200102280457.f1S4vYQ19924@wally.eecs.harvard.edu> <3A9C8DFA.ABC44BA1@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
The card can take care of translating virtual to physical addresses
and can DMA directly into user space, there's no need for mmap
tricks.  It also supports reading from a remote process virtual
address space without involving the remote processor.  In this
setting, I don't see how to use sockets to have logical instances of
the card.  I would also like to avoid hacking the rest of the kernel,
I'd like to contain everything in the driver.

BTW, just to give you an idea of what I'd like to have, Linux passes
the file structure as a parameter to device operations (along with the
inode), and the file structure has a private data space that the
driver is free to use for storing state associated with the opened
"instance" of the device.  In FreeBSD, it is only a specinfo * and the
proc * that is passed, and I can't use this information alone to map
to the "file".


   From: Julian Elischer <julian@elischer.org>

   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?200102280630.f1S6UoW07894>