lkml.org 
[lkml]   [2008]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 3/4] Fix remaining big endian issue of hfcmulti
From
Date

> But do we really need a generic driver that can do either? Maybe for the
> current mISDN driver, but when you get to other chip ports, say the
> xhfc, you have to select the low level interface at compile time. Or I
> should say you currently have to select at config time.

Which is pretty wrong thing to do. It might work fine for a specific
case of an embedded vendor building one ad-hoc kernel for the device,
but look at this from the point of view of a linux distribution shipping
a generic kernel image & built modules to support any HW out there...

> I'm not arguing that we *have* to do it this way. I just don't think we
> should throw out the simplest method without some thought. There is
> some precedence for a config time option, for example the 8139too
> ethernet driver.

Well, yeah, we made mistakes in the past :-)

If the size of the binary (or performances) involved in doing the two
type of IOs in a single driver is such that having the ability to
only use one is worth it (for embedded for example), then you can
provide a config option that allows to select which method to build
in the driver, but it's a good idea to allow building both with
runtime detection.

Ben.



\
 
 \ /
  Last update: 2008-08-06 01:07    [W:0.139 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site