Subject: Re: [seamoby] An API issue

From: kempf <[email-masked]>
Date: Wed, 16 May 2001 16:53:46 -0700 (PDT)

Randy,

>This seems like a real naive question I know... but when you
>start digging in to at least most unixy stacks, you have 
>a layer 2 driver servicing the card (or is it layer 1:>),
>its interfaces to upper layers are:
>
>A) ioctl... user requests/response model
>B) packet arrival -> submit to ether_input()
>C) packet sending -> output routine is called.
>
>
>Now I can use A if you want to have the interested upper
>layer poll every N interval and ask... hey what is your
>current status? But this means that N becomes the granularity
>of when you might want to handoff/do something. This could
>be a real problem for real time services...
>

How about a thread that blocks on the ioctl() and returns when
the Layer 2 event occurs? After all, this is 2001 and while
we may not have cities on the moon and spaceships to Juipiter,
most operating systems now support multithreading at the
user level.

		jak

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 16 May 2001 21:13:34 -0500

> most operating systems now support multithreading at the
Hmm.. I suppose a blocking ioctl could be done... something
like 

ioctl(TELL_ME_WHEN_I_LOSE_THE_AR);

That blocks... but my question is far deeper than such a naive
ioctl()... I think there may be more things I want to know
besides I can see an AR and I can't see an AR... maybe I am
just attempting to make this too complicated... but a blocking
ioctl() crossed my mind but I dismissed it...

Of course another reason may also be that I dis-like threads :)

R

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 17 May 2001 10:01:06 -0500

> most operating systems now support multithreading at the
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..

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..

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... 

R