Subject: Re: [seamoby] An API issue

From: kempf <[email-masked]>
Date: Thu, 17 May 2001 18:46:59 -0700 (PDT)

>Jim:
>
>I have did a bit more digging and your naive approach sounds
>good at first glance... until you start to dig in to the stacks..
>at least a BSD stack. I would imagine that the sun streams based
>drivers are pretty much the same..
>
>ioctl()'s (which become a put down on to the stream if I
>remember sunism's/att's stream code) call down
>the stack with a data pointer attached. When directed
>down to the driver level, the driver not being aware of
>sockets, just copies back to the user space pointer. For
>a streams like thing I would imagine the driver gets (in
>the end) a message asking for something with a reply
>address/stream. It then replies to that stream. If one
>wants to block for the ioctl case it is pretty hard since
>there is a fundamental seperation of the blocking type
>things i.e. a socket and the driver level. Sure I can
>hack up this level.. but that is very in-elegant. I bet
>if you dig into the sun code you will find similar traits..
>
>The drivers live at a boundary below the blocking/non-blocking
>wakeup level.. It is well suited for two types of things:
>
>1) Passing messages in/out to the wire
>2) Answering requests (i.e. ioctl's) right away.
>
>which is what a network driver needs to do in general.
>
>By changing this layering you get all sorts of fun..
>

Why do you have to do the ioctl on the socket? It you are looking for
an L2 trigger, you should be getting it directly from the driver, so
the ioctl should be done on a file descriptor opened directly on
the device. Or am I missing something?

Of course, if you don't like threads in the first place, there's
no point in doing it. I happen to like threads, so that's probably
how I would do it.

>So far if I am going to hack this in it is probably better
>to take Marco's suggestion and add a pseudo device... reason
>being is that most net drivers don't have a appearance in
>the /dev directory or any place to open them up :< 
>
>A pseudo device could solve this... but it is still not
>the general purpose solution I would like to see..
>

That would work. It's putting in a new device to handle the ioctl,
instead of directly using the interface. May have some implementation
advantages.

>I think a more elegant and general approach would be to
>design an new socket type. Add a new ether type and 
>design general purpose data structures that could
>be passed up from the driver(s). Then you would
>end with a very generic solution that can be blocked/selected
>for read blocking or whatever...
>
>Mores to the point you would have a standard data
>interface for Layer-2 triggers... 
>

Hmm, good point. There's currently no way to do out of band
signalling on SOCK_DGRAM or SOCK_STREAM sockets. Maybe you've come
up with something for SOCK_SCTP?

		jak

---

From: "Randall R. Stewart" <[email-masked]>
Date: Fri, 18 May 2001 07:04:34 -0500

Answer below...

> the device. Or am I missing something?
Well, network devices often times do NOT have an appearance
that you can open... i.e. there is no /dev/ep0 or /dev/dc0
or /dev/sis0 in any of my bsd machines..

You can find them with ioctl's and such and some other
calls.. but they have no read/write service routine...

> instead of directly using the interface. May have some implementation

Doing Marco's suggestion does give you the read/write hooks...

> up with something for SOCK_SCTP?

No, SCTP has nothing to do with this... this is more in-line
with AF_ROUTE socket... after all its a routing event that
is transpiring.. sort-of :/

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)