Messages in this thread |  | | Date | Sat, 31 Jul 2004 10:33:08 +0200 | | From | Willy Tarreau <> | | Subject | Re: PATCH: VLAN support for 3c59x/3c90x |
| |
Hi Herbert,
On Sat, Jul 31, 2004 at 01:57:04PM +1000, Herbert Xu wrote: > Willy Tarreau <willy@w.ods.org> wrote: > > no, because the driver has no change_mtu() function, so it uses the generic > > one, eth_change_mtu(), which is bound to 1500. > > What is preventing you from implementing a change_mtu() function?
well, now I see where you want to bring me :-)
So several reasons : - the change_mtu() function might be called at any time after driver initialization. I don't know at all if there are things to do to "lock" the hardware during such changes, as well as I don't know what parts of the code I will need to extract to change the hard MTU. The initial MTU is really different since it's used to initialize hardware registers. The generic change_mtu() function only plays with dev->mtu and not hardware since it never goes above standard size. I could try, but if it works I would offer no warranties for other hardware.
- I really, really, really... lack time. I would do this during my few hours nighty sleep and I wouldn't want to use the resulting code :-)
- many (all ?) other drivers already have an MTU parameter, and many of them don't have a problem with using generic change_mtu(). So why would this one in particular need such a change ? (and please don't tell me that *I* will have to do this for all others :-))
As previously said, I can take a few minutes to add the 'MODULE_PARM' line, it's not much more than replying to this mail. At least it will be a good start.
Cheers, Willy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |