On Thu, 16 Sep 2004, Godfrey van der Linden wrote:
>
> G'day All,
>
> Let's talk about the match category solution then.
>
> <snip>
>
> One last thing, I'm not sure that I agree with JohnD's statement
> > Note that a much easier way to do the above even with nubs would be to
> > just pass the string that you want to match against into the init
> > method of the nub. Hardcode them! It's not like your hardware is going
> > to grow new chips.
> This statement is right as far as this particular driver is concerned,
> However my experience is that the hardware evolves and the driver also
> evolves. I find that Hardware designers are sort of like software
> engineers and one of the easiest and most powerful things to do is to
> add multiple cells to the FPGA. If you design the Master driver
> properly you can describe these additional cells in the OSArray in your
> personality and not have to change the driver at all.
>
> Also hardc oding isn't really that nice a solution in anycase. It
> requires less code to walk through an array in your matching
> IOKitPersonality then it takes to hard code the creation of the nubs
> one at a time.
I guess I just had in mind the difference between an OSIterator
traversal and a 'for (i=0; i<sizeof(names)/sizeof(*names); i++)' loop. But
yeah, it was mainly a reaction against a solution I saw as overly general
for the specific case.
> BTW this isn't theoretical. I really have developed a driver where the
> Master driver didn't have to change when a new cell was added. We just
> defined the parameters in the personalities array and matched the next
> level driver. This was so we could use the same drivers for 2
> different types of hardware (pro & prosumer).
For sure, if you have the kind of hardware that is modular or easily
extensible like that (e.g. you have a bus to address diferent bits of it)
then making a modular driver that creates nubs is a good idea.
'Tho in the past I have spent way more time writing general code that
never got extended use (or not in a way that didn't need further
unanticipated modification anyway) than saved time by using a system I'd
set up earlier.
OTOH I agree that it's a good discipline if it doesn't complicate things.
Just my 2c.
> Godfrey
{P^/
btw Should probably mention that last Wednesday I managed to reuse a
driver I'd written (for another manufacturer's card!) with the addition of
a new small subdriver that matched to one of the nubs it put out. In fact
it was kinda unintentional as the pci-level driver just matched on the
primary key and did its thing as soon as it was loaded, before I'd even
started development ... hmm gotta put in those pci subsystem id match keys
at some stage :)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-drivers/email@hidden
This email sent to email@hidden
