Geert,
How much lower? Enough to matter? Implicit in that question is
the assumption that this is largely a hobbyist platform and nobody
is using it in a closet to route gigabytes of traffic.
One other thing we could do is increase CONFIG_HZ to 250.
Making 3.x kernels run even more sluggish than they already do?
Also, the only advantage to modifying ne.c is to allow dumping
the old driver. What is the "remove soon" plan? Any reason
for it to not be synchronous? That would eliminate the Kconfig
churn and the introduction of the _OLD option. Modifying ne.c
and then deciding to keep the old driver because it is "faster"
would make this change pointless.
From my point of view, "remove soon" means it will never hit mainline.
That's what I meant to say - my patch is based on the m68k tree which
currently has another driver for this hardware, based on an older
version of ne.c which was never submitted to mainline. The old driver
would be removed from the m68k tree as soon as possible.
This seems more klunky than it needs to be. If we assume that anyone
building ne.c on atari is hence trying to drive an ethernec device
than it can just be
#ifdef CONFIG_ATARI
#define EI_IRQ_FLAGS IRQF_SHARED
#else
#define EI_IRQ_FLAGS 0
#endif
Indeed, with a small modification (keep multi-platform kernels in mind):
#ifdef CONFIG_ATARI
#define EI_IRQ_FLAGS (MACH_IS_ATARI ? IRQF_SHARED : 0)
#else
#define EI_IRQ_FLAGS 0
#endif
Right you are. Is any other m68k platform using ne.c directly, or do you
plan to convert all other NE2000 based drivers to ne.c now?
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
