Re: User-space controlled raw ethernet - Is this the way to go?



On Mon, 25 Feb 2008 15:39:29 +0100 Jan Kandziora <jjj@xxxxxx> wrote:
| phil-news-nospam@xxxxxxxx schrieb:
|>
|> I've said this years ago. It applies here, too. All network interfaces
|> should have been device nodes. Then you could let a process open one of
|> them in the normal I/O way (as long as it is not busy from being an active
|> network interface). An ethernet port is really not much more than a fancy
|> serial port.
|>
| With Linux, such a function is both easy to implement and relatively
| useless. From kernel's point of view, the actual port could be exposed at
| most the way you'll described: if the Linux kernel does not "claim" the
| interface, a userspace program may do.

But where do you store the permissions and ownership (e.g. a user that
is allowed certain access)? With a device nice file, there it is. But
without one, then where?


| The network code is one of the biggest in-kernel applications Linux have.
| All the address handling, filtering, routing is done within this kernel
| application -- mostly for speed reasons, Linux' networking is really fast
| because of it.

And a device node would not change that. It would merely be a way to
access the device as a file. Networking code could still all work the
same. It would be optional for ifconfig to reference the interface to
configure by means of opening the device node and passing the descriptor
(how I would have suggested designing it from the beginning). But it
can just do it the way it does now, anyway.


| In a microkernel, one certainly *would* go the way you described, exposing
| the raw interface to the userspace and let a demon do all the work, but
| within Linux, passing all the ethernet data to a device node is just a
| function without too many use cases.

Yes, it would be rare to use an ethernet port other than as a network
interface. But I still think that it would not have been hard to do it
right from the beginning, if the designers had intended to keep things
consistent in the whole principle of having all devices be files.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-02-25-2203@xxxxxxxx |
|------------------------------------/-------------------------------------|
.



Relevant Pages

  • Network interrupts
    ... I am a newbie trying to bring up a board on MontaVista Linux. ... board has an Intel IOP321 processor with an ARM core. ... the interface was configured correctly. ... IntelPRO/1000 Network Driver - version 5.0.43 ...
    (comp.os.linux.embedded)
  • Re: Ethernet cable check
    ... >>nonfunctional network. ... >>the way if I later fire up the wireless interface. ... with linux around the same time i started opening PCs up and looking ... cards and not have ifconfig tell me which one had a "good physical link" ...
    (Fedora)
  • Re: Still no network...
    ... Linux box to see the network (2 Windows boxes ... Do NOT mix a local network with the ISP connection. ... need a 2nd interface for the LAN. ...
    (alt.os.linux)
  • Re: Virtual ip on linux not working on the network
    ... The above 'route' statement is not required, as adding an interface ... | but on the network i cant reach the ip 192.168.1.200. ... | What is the real way to make a virtual ip on linux and what i have to ...
    (comp.os.linux.networking)
  • [PATCH 1/1] IPN: Inter Process Networking
    ... +IPN is an Inter Process Communication service. ... +interface and protocols used for networking. ... +to a "network". ... +creates a communication socket. ...
    (Linux-Kernel)