> I'm working on the implementation of the newer RFC 1201 method of IP over
> ARCnet, which does link level fragmentation and reassembly.

hmm.  i think i'd call that "cute."  8-)

I just looked up the relevant RFCs, and i can confidently say that my
stomach is not any better off for it.  8-)

> Unfortunately, the header format (but also packet type number) is changed 
> wrt. RFC 1051.

You mean the "protocol ID" number (as described in 1201)?

> My idea was to make the format switchable through the
> link0 flag.

This seems like it could be reasonable; have arc_output switch on that
type, and DTRT with the packets...

> I would like to keep the details of header coding out of the hardware
> drivers as much as possible. So, I would 
> 
> - add a 
> 
> void arcfilter(struct mbuf *m)
> 
> to /sys/net/if_arcsubr.c, which would give the recoded (to 1051 format)
> packet to the packetfilter input, if it was a "first" packet, and else
> ignore it. The hardware drivers would no longer call the bpf stuff themselves.

This seems wrong to me for a couple of reasons:
	(1) the "packet filter" wants to see packets _as they come in_
	    over the network; if it doesn't, it can't be as useful when
		debugging network problems.

	(2) it's not clear to me what this arcfilter() would do.

It seems to me that stuff like reassembly, and, indeed, most of the
work in fishing the data out of the packets, should be done by arc_input().

> However, one issue stays unresolved: The two types of headers have
> different alignments. The hardware driver would have to switch alignment
> if the flag is changed but this would work only for IP and IP-ARP.
> Should the hardware driver look at the packet type itself before
> deciding on the alignment? Should it ask a function (or an array) in
> if_arcsubr for the preferable alignent? (Array would be 256 bytes). 

I don't understand what you mean.  First, what do you mean by
"alignment"?  second, in what ways are the headers "aligned"
differently?  i notice that the 1201 packets can contain a bunch of
NUL padding in the header (YECH!), is that what you mean?

In particular, looking at 1051 vs 1201, i see the only differences at
the front of the packet headers:

	the "ALERT*" bits in the 1051 header,
	the SOH bits in the 1051 header.

As far as i can tell (from reading the RFCs; no practical experience
8-), those are "on-the-wire only", i.e. they don't show up to the
software.  is that incorrect?  In any case, since 1201 says that it
can operate on the same wire as 1051 (but not understand 1051 packets,
and vice-versa), it would seem to be that there _has_ to be a decent
way to tell the packets formats apart.  I would guess (from looking at
the RFCs) that the header formats are the same, at least up to the
"system code"/"protocol ID".

I'm not at all sure what the "preferable alignment" array would be
needed for?  what do you think you need to know it for?



It also seems that all of the stuff you're dealing with are
(effectively) chars, or structures comprised of chars.  Given that
(and given GCC's somewhat depressing attempt to pad e.g. structures of
three chars to 4 bytes...), you may need to do something odd with
just addressing things as arrays, or something, rather than as
structure members (though i'd rather not see "packed" declarations, or
things like that 8-)...

It looks like an awful lot of "generic arcnet input" processing is
currently being done in the driver's receive interrupt, and could be
pushed into arc_input().  In particular, since all of the 1051/1201
processing seems to be board-independent (is it?), it could all go at
the if_arcsubr.c layer.  I don't think that there's anything written
in stone saying that the "media input" routine (i.e. arc_input()) has
to take (interface, header, mbuf chain) as its parameters; you should
be able to call it with (interface, mbuf chain), and let it deal with
all of the ARCnet processing...


thoughts?


cgd