Character driver -> networked device
William Waddington
First, let me apologize for my utter cluelessness ... I have no idea
whether what I am trying to do is trivial or impossible.
We manufacture a line of Pci boards that attach directly to plotting
devices. Those boards are currently supported with Linux (and Solaris &
HPUX) open-source drivers. Our new product is an external box that allows
attaching these plotting devices to the network. It works well with FTP,
and various network printing protocols supported by the print server that
we use internally.
What I would like to do is write a character driver module that looks to
applications like our Pci driver, but actually communicates via the
network. So, the question is: can I get at the network from within a
character driver module?
Pointers at news groups, code, howtos, books, and advice in general is
greatly appreciated.
TIA,
Bill
---------------------------------------
Bill Waddington
Bainbridge Island, WA, USA
csbwad...@att.net
waddi...@tahomatech.com
---------------------------------------
Grant Edwards
> character driver module?
Yes, but it's not trivial. AFAIK, you've got to create the
network connection (create the socket and connect it) in
userland and pass it to the kernel driver with an ioctl(). At
that point, you can read/write data from kernel-space. You've
got to know some of the internals of the IP stack to do so, but
it can be done. There's not an "official" API to allow device
drivers to do stuff like that.
That's all assuming you want to do IP stuff. If you want to do
your own non-IP Ethernet proto, then that's completely different.
> Pointers at news groups, code, howtos, books, and advice in
> general is greatly appreciated.
If somebody knows of the "proper" way to do this, I'd like to
hear about it also.
--
Grant Edwards grante Yow! An air of FRENCH
at FRIES permeates my
visi.com nostrils!!
William Waddington
>> So, the question is: can I get at the network from within a
>> character driver module?
>
>Yes, but it's not trivial. AFAIK, you've got to create the
>network connection (create the socket and connect it) in
>userland and pass it to the kernel driver with an ioctl(). At
>that point, you can read/write data from kernel-space. You've
>got to know some of the internals of the IP stack to do so, but
>it can be done. There's not an "official" API to allow device
>drivers to do stuff like that.
Thanks Grant,
That's probably way deeper than my modest abilities will allow.
Maybe I'm going at this from the wrong end. What I need is to allow
existing applications to do:
open(/dev/something ... )
ioctl()
write()
close()
ioctl will translate some args/ops into byte strings to go out on the
network along with write data. I need to look like an ftp client, or one
of the supported print clients.
Is there any way to generate a /dev entry that when opened calls code that
exists entirely in userspace? Sorry if that's a totally meaningless
question.
Thanks again,
Grant Edwards
> On Wed, 12 Sep 2001 18:27:11 GMT, gra...@visi.com (Grant Edwards) wrote:
>
>>> So, the question is: can I get at the network from within a
>>> character driver module?
>>
>>Yes, but it's not trivial. AFAIK, you've got to create the
>>network connection (create the socket and connect it) in
>>userland and pass it to the kernel driver with an ioctl(). At
>>that point, you can read/write data from kernel-space. You've
>>got to know some of the internals of the IP stack to do so, but
>>it can be done. There's not an "official" API to allow device
>>drivers to do stuff like that.
>
>
> Maybe I'm going at this from the wrong end. What I need is to
> allow existing applications to do:
>
> open(/dev/something ... )
> ioctl()
> write()
> close()
>
> ioctl will translate some args/ops into byte strings to go out
> on the network along with write data. I need to look like an
> ftp client, or one of the supported print clients.
>
> Is there any way to generate a /dev entry that when opened
> calls code that exists entirely in userspace? Sorry if that's
> a totally meaningless question.
No, it's not a totally meaningless question.
One way to do something like that is to use a pty device. The
userland program opens one end of the pty (which is a character
device that looks just like a serial port), and you have
another user-task task that is at the other end of the pty and
does network I/O. That task only sees data from the read/write
requests, the pty device only does the stanadard serial port
ioctl() stuff, so that doesn't sound like something that would
work for you.
It would be cool to have a user-mode driver scheme (similar to
the one for user-mode filesystems). And it wouldn't be that
hard either... Hmm...
--
Grant Edwards grante Yow! I'm in DISGUISE as a
at BAGGAGE CHECKER....I can
visi.com watch the house, if it's
ORANGE...
Norm Dresner
news:ejavptkt1m8jf8g5f...@4ax.com...
> On Wed, 12 Sep 2001 18:27:11 GMT, gra...@visi.com (Grant Edwards) wrote:
>
> >> So, the question is: can I get at the network from within a
> >> character driver module?
> >
> >Yes, but it's not trivial. AFAIK, you've got to create the
> >network connection (create the socket and connect it) in
> >userland and pass it to the kernel driver with an ioctl(). At
> >that point, you can read/write data from kernel-space. You've
> >got to know some of the internals of the IP stack to do so, but
> >it can be done. There's not an "official" API to allow device
> >drivers to do stuff like that.
>
> Thanks Grant,
>
> That's probably way deeper than my modest abilities will allow.
>
> Maybe I'm going at this from the wrong end. What I need is to allow
> existing applications to do:
>
> open(/dev/something ... )
> ioctl()
> write()
> close()
>
> ioctl will translate some args/ops into byte strings to go out on the
> network along with write data. I need to look like an ftp client, or one
> of the supported print clients.
>
> Is there any way to generate a /dev entry that when opened calls code that
> exists entirely in userspace? Sorry if that's a totally meaningless
> question.
>
Within the Real-Time Linux enhancements to Linux is a real-time FIFO which
can communicate between (real-time) device drivers and user programs fairly
easily. Since you're looking to sell products to ordinary Linux users
that's not practical but there may be some other normal-Linux mechanism you
can use. For example:
Create a daemon that opens a separate minor on your major device and
then executes a blocking read. Whenever the driver has something to send
out it can shove it into the daemon which has perfectly normal access to
network things. That's the simplest way I know to emulate a real-time FIFO
with normal Linux and it's more appropriate since you really don't have any
need for a hard real-time system.
Norm
William Waddington
wrote:
Thanks Grant & Norm,
The daemon/separate minor # looks like it might fly. I haven't done a
driver w/interaction between minor #s, so I've got some homework to do.
(Not to mention learning the userland networking stuff - any pointers to
resources?)
Thanks again to both,
Terran Melconian
William Waddington <csbwad...@att.net> wrote:
>The daemon/separate minor # looks like it might fly. I haven't done a
>driver w/interaction between minor #s, so I've got some homework to do.
>(Not to mention learning the userland networking stuff - any pointers to
>resources?)
For the drivers, the Rubini book (assuming you don't already have it):
http://www.oreilly.com/catalog/linuxdrive2/
For the network, get W.R.Stevens "Unix Network Programming." Vol 1.
is the most important for what you're doing, but if your company is
paying, get the set ;).
Grant Edwards
>>> Is there any way to generate a /dev entry that when opened calls code that
>>> exists entirely in userspace? Sorry if that's a totally meaningless
>>> question.
>>
>>Within the Real-Time Linux enhancements to Linux is a real-time FIFO which
>>can communicate between (real-time) device drivers and user programs fairly
>>easily. Since you're looking to sell products to ordinary Linux users
>>that's not practical but there may be some other normal-Linux mechanism you
>>can use. For example:
>> Create a daemon that opens a separate minor on your major device and
>>then executes a blocking read. Whenever the driver has something to send
>>out it can shove it into the daemon which has perfectly normal access to
>>network things. That's the simplest way I know to emulate a real-time FIFO
>>with normal Linux and it's more appropriate since you really don't have any
>>need for a hard real-time system.
That's a pretty good suggestion and requires minimum amount of
kernel-mode futzing.
> The daemon/separate minor # looks like it might fly. I haven't done a
> driver w/interaction between minor #s, so I've got some homework to do.
> (Not to mention learning the userland networking stuff - any pointers to
> resources?)
W. Richard Stevens books "UNIX Network Programming" is pretty
much the definitive source for network programming. IIRC
Volume 1 contains the stuff you want.
There's also
http://www.linuxports.com/howto/networking/
--
Grant Edwards grante Yow! Am I accompanied by
at a PARENT or GUARDIAN?
visi.com
William Waddington
>In article <r5evpt4d7o4v04r3b...@4ax.com>, William Waddington wrote:
>
>>>> Is there any way to generate a /dev entry that when opened calls code that
>>>> exists entirely in userspace? Sorry if that's a totally meaningless
>>>> question.
>>>
To follow up to my own initial post, coincidentally, this showed up on
LKML. Looks like it might be _very_ useful if it performs as advertised.
http://www.circlemud.org/~jelson/software/fusd/docs/fusd.html
To quote from the above link:
"What is FUSD?
FUSD (pronounced fused) is a Linux framework for proxying device file
callbacks into user-space, allowing device files to be
implemented by daemons instead of kernel code. Despite being implemented in
user-space, FUSD devices can look and act just like any
other file under /dev which is implemented by kernel callbacks. "
I haven't tried it yet, and may not, as I need something that plays with
Linux and Solaris, if at all possible.
Thanks to all,