Garrett D'Amore wrote: > The IFSPEED() macro should probably be confined to the bowels of the > mac_ether.c implementation.
I suppose I had hoped this macro could be used in a wider context (dnet could certainly use a macro like this as well as others). It seems that the bulk of drivers just multiply the speed which can be error prone (easy to catch though). Maybe a premature feature or wishful thinking? > I'm a little confused though about mc_notify. Who calls this, and > when? I *suspect* that the role is reversed here, and rather than > mc_notify() being an entry point in the driver, its the other way > around, and the driver should call mii_notify() to make the framework > understand that a change has happened. This was something I struggled with too. The existing mii code (/usr/src/uts/intel/io) uses a structure similar to this. Essentially, a portmon is spawned which uses a timeout to poll for state. I like it from the perspective that the driver developer does not have to care about state changes (which may or may not be interrupt driven anyway) when using an MII xcvr. I don't like polls, but a poll issued every second or more shouldnt impact throughput noticably, especially since the resultant call should make a single PIO read. Of course, my experience so far has been with fast ethernet and gigabit ethernet - I honestly have no idea if this could impact wirespeed on faster chipsets. > The other tidbit is that I'm not entirely sure that the drivers need to > have access to the mii_xxx functions directly. While they could be > useful, I think I see them being *more* useful to the framework itself. This was an artifact of the original mii code as well. I suppose the gist of this was to support manual configuration rather than forcing a driver to configure a manual link by bypassing mii. > To that end, it does also seem that the framework could do with knowing > that the part is an MII based device, and hence provide mii-equivalents > for some of the functionality that currently exists in device drivers > directly. (I'm thinking for things like mac_stat() and the Brussels > property interfaces.) Definitely. I'm not completely familiar with Brussels support (yet), but I did add a call (mii_getstat) to support MII kstats. This may not be the best approach (I was thinking it would be a combination of ETHER_STAT_ISMII and mii_getstat). I am definitely curious if there are any other established patterns for this kind of behavior. Were there any crucial operations or behavior that I missed? This has been deceptively easy (so far) and I even have a fair amount of impl code complete. Also, I suspect that I will need to pick a driver to use as a guinea pig. Any suggestions? (afe seems a likely candidate since the code is well written and already has its own MII impl which should reveal any missing functionality). Regards, Steve _______________________________________________ networking-discuss mailing list [email protected]
