Re: [9fans] fs kernel ether driver update

Re: [9fans] fs kernel ether driver update

[geoff]

I've just updated the fs igbe driver after verifying that the new one
works.

I discovered that the dp83820 driver didn't recognise the linksys
eg1032, which surprised me, and upon modifying the driver to recognise
the pci vid and did, the driver wedges the machine such that only a
front-panel reset will reset it.

Re: [9fans] fs kernel ether driver update

[Charles Forsyth]

>>Also would be nice if Inferno and standard Plan 9 kernel drivers
>>lived in a single source tree.

it's tricky to do exactly that without an impractical degree of coordination
(for instance, about interface changes).  but because it is silly to have
to maintain two sets of drivers for systems with too few anyway, i periodically
try to bring Inferno's set into close approximation.  (now i need to make
further changes to account for the revised plan 9 vm interface for drivers.)
rather unfairly, things don't often go the other direction, because
most of my own native Inferno work is arm and powerpc, not pc, or it's a similar
pc to ones used for plan 9 and drivers already exist.

Re: [9fans] fs kernel ether driver update

[geoff]

As far as I know, the reason for drivers being different in fs and cpu
kernels is divergent, or at least independent, evolution.  The fs
kernel started as an old cpu kernel.  My impression is that Ken wanted
to keep fs kernel changes to a minimum to maximise stability of the
file servers.

The major ethernet drivers in the fs kernel will now compile in the
cpu kernel too, and I run these unified drivers in all my kernels.
The differences are fairly small: different headers have to be
included, some names have to be mapped to other names, the fs kernel
needs some of the cpu kernel's infrastructure or emulation thereof
(see /sys/src/fs/pc/compat.[ch]) and a few operations have to be
expressed a little more abstractly (usually as macros in my
implementation).  There are a few other differences not papered over
as cleanly: maintaining one's own pool of buffers (vs the Mbrcvbuf
flag in the fs kernel), and a change in tests against the PCI ccru
struct member, which is different sizes in the two kernels.

Apparently /sys/src/9/pc/compat.h has changed a little since I posted
it in November 2002, so here's the current one:
---
/*
 * compatibility hacks to permit drivers from the cpu/terminal kernel
 * to be moved to the fs kernel (and eventually 9load)
 */
#define ETHERIQ etheriq
/*
 * cpu kernel uses bp->rp to point to start of packet and bp->wp to point
 * just past valid data in the packet.
 * fs kernel uses bp->data to point to start of packet and bp->data+bp->count
 * points just past valid data.
 */
#define SETWPCNT(bp, cnt)	(bp)->wp = (bp)->rp + (cnt)
#define BLKRESET(bp)		(bp)->wp = (bp)->rp = (bp)->lim - Rbsz
#define INCRPTR(bp, incr)	(bp)->wp += (incr)
#define ENDDATA(bp)		(bp)->wp

#define etheroq(edev)		qget((edev)->oq)
#define PROCARG(arg)		arg
#define GETARG(arg)		arg
---

Re: [9fans] fs kernel ether driver update

[uriel]

I'm sure there is a good reason for this, but I was wondering what would
it take for the fs kernel and the standard kernel to shared the drivers source.

Also would be nice if Inferno and standard Plan 9 kernel drivers lived in a single
source tree.

uriel

> I just put up a second file server for testing.  This one has a
> built-in SiS ethernet and I was able to exercise it; it seems to be
> fine with the current driver.  (I did have to change the boot programs
> to recognise the SiS interface, and those changes have been submitted
> as a patch, and still require one to specify ea= in plan9.ini for SiS
> interfaces.)
>
> I've also exercised an i82557 with a new driver.  It seems to be fine,
> so I've copied that driver to
> /n/sources/plan9/sys/src/fs/pc/ether82557.c.  Like ether83815.c,
> ether8139.c, etherdp83820.c, and etherigbe.c, this new 82557 driver
> will work unmodified in cpu kernels that have /sys/src/9/pc/compat.h.
>
> There are more driver updates coming as I get the chance to verify
> that the new drivers work correctly.

Re: [9fans] fs kernel ether driver update

[geoff]

Right, both the cpu and fs drivers dig the mac address out of rom.  I
haven't gone to the trouble yet in the boot driver.

Re: [9fans] fs kernel ether driver update

[Federico Benavento]

> It doesn't need it with the current *boot* driver
> (/sys/src/boot/pc/ether838315.c)?  Mine definitely needs it.
>
>
sorry, I was talking about /sys/src/9/pc/ether83815.c.

--
Federico G. Benavento

Re: [9fans] fs kernel ether driver update

[geoff]

> hmmm, my SiS 900 rev 630s doesn't need ea= in plan9.ini with the
> current driver.

It doesn't need it with the current *boot* driver
(/sys/src/boot/pc/ether838315.c)?  Mine definitely needs it.

Re: [9fans] fs kernel ether driver update

[Federico Benavento]

> as a patch, and still require one to specify ea= in plan9.ini for SiS
> interfaces.)
>

hmmm, my SiS 900 rev 630s doesn't need ea= in plan9.ini with the current driver.

> There are more driver updates coming as I get the chance to verify
> that the new drivers work correctly.

great!

--
Federico G. Benavento

[9fans] fs kernel ether driver update

[geoff]

I just put up a second file server for testing.  This one has a
built-in SiS ethernet and I was able to exercise it; it seems to be
fine with the current driver.  (I did have to change the boot programs
to recognise the SiS interface, and those changes have been submitted
as a patch, and still require one to specify ea= in plan9.ini for SiS
interfaces.)

I've also exercised an i82557 with a new driver.  It seems to be fine,
so I've copied that driver to
/n/sources/plan9/sys/src/fs/pc/ether82557.c.  Like ether83815.c,
ether8139.c, etherdp83820.c, and etherigbe.c, this new 82557 driver
will work unmodified in cpu kernels that have /sys/src/9/pc/compat.h.

There are more driver updates coming as I get the chance to verify
that the new drivers work correctly.