Matthew Wilcox wrote:
>Actually I think the generic device model is crap. [...]
My patch is a net deletion of 57 lines and will allow simplification
of parisc DMA allocation.
Although I agree with most of your criticisms about the generic device
model, most of the problems with it are the way people use it (the
first thing everyone wants to do is a driverfs file system) and some
conventions that I disagree with, such as the idea that drivers that
embed struct device and struct device_driver should not initialize
those fields directly, but should have xxx_register_device copy them
in. parisc can use the generic driver API without getting fat.
Problems specific to the generic device API can be incrementally
improved and nobody is treating it as set in stone. I think the
generic device API is close enough already so that it's worth porting
to, even if future clean-ups will then require some small changes to
the code that is ported to it.
Please do not throw the baby out with the bath water. The generic
driver interface in its present form really can make parisc smaller
and cleaner.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Miplitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Fri, Nov 08, 2002 at 08:51:28PM -0800, Adam J. Richter wrote:
> My patch is a net deletion of 57 lines and will allow simplification
> of parisc DMA allocation.
57 lines of clean elegant code, replacing them with overly generic ugly
code and bloated data structures. struct device is a round 256 bytes
on x86. more on 64-bit architectures.
> in. parisc can use the generic driver API without getting fat.
no. it can't.
> Problems specific to the generic device API can be incrementally
> improved and nobody is treating it as set in stone. I think the
> generic device API is close enough already so that it's worth porting
> to, even if future clean-ups will then require some small changes to
> the code that is ported to it.
Everyone's saying "ra! ra! generic device model!" without asking
what the cost is. Don't you think it's reasonable that _as the most
common device type_, struct device should be able to support PCI in a
clean manner? Don't you think that the fact that it fails to do so is
a problem? Don't you look at the locks sprinkled all over the struct
device system and wonder what they're all _for_?
Don't get me wrong. I want a generic device model. But I think it's
clear the current one has failed to show anything more than eye candy.
Perhaps it's time to start over, with something small and sane -- maybe
kobject (it's not quite what we need, but it's close). Put one of those
in struct pci_dev. Remove duplicate fields. Now maybe grow kobject a
little, or perhaps start a new struct with a kobject as its first member.
And, for gods sake, don't fuck it up by integrating it with USB too early
in the game. Let's get it right for PCI, maybe some other internal busses
(i'm gagging to write an EISA subsystem ;-). SCSI is more interesting
than USB. Above all, don't fall into the trap of "It's a bus and it
has devices on it, therefore it must be a part of devicefs".
*sigh*. halloween was a week ago.
--
Revolutions do not require corporate support.
On Sat, Nov 09, 2002 at 05:21:50AM +0000, Matthew Wilcox wrote:
>
> Everyone's saying "ra! ra! generic device model!" without asking
> what the cost is. Don't you think it's reasonable that _as the most
> common device type_, struct device should be able to support PCI in a
> clean manner?
No I do not.
> Don't you think that the fact that it fails to do so is a problem?
Yes I do.
> Don't you look at the locks sprinkled all over the struct device
> system and wonder what they're all _for_?
Nope :)
(yes, I do wonder, and yes, they will be cleaned up...)
> Don't get me wrong. I want a generic device model. But I think it's
> clear the current one has failed to show anything more than eye candy.
> Perhaps it's time to start over, with something small and sane -- maybe
> kobject (it's not quite what we need, but it's close). Put one of those
> in struct pci_dev. Remove duplicate fields. Now maybe grow kobject a
> little, or perhaps start a new struct with a kobject as its first member.
No, lets start pulling stuff out of pci_dev and relying on struct
device. The reason this hasn't happened yet is no one has been willing
to break all of the PCI drivers, yet.
I know Pat is going to be doing this soon, and if he doesn't get to it,
I will. But as Adam said, don't throw away the idea because it looks
crufty now. This has been a _constantly_ evolving model as we work to
get it right. It will take time, and we are still getting there.
> And, for gods sake, don't fuck it up by integrating it with USB too early
> in the game.
In my defense, USB was the _only_ bus willing to step up and try to do
the integration to work the initial kinks out. The SCSI people are
being drug kicking and screaming into it, _finally_ now (hell, SCSI is
still not using the updated PCI interface, those people _never_ update
their drivers if they can avoid it.)
> Let's get it right for PCI, maybe some other internal busses
> (i'm gagging to write an EISA subsystem ;-). SCSI is more interesting
> than USB. Above all, don't fall into the trap of "It's a bus and it
> has devices on it, therefore it must be a part of devicefs".
Sure SCSI's more interesting, to you :)
By having USB be one of the first adopters (after PCI), we have found a
_lot_ of issues and bugs that happened due to devices showing up and
disappearing at odd times. Which was _much_ easier to debug than PCI
would have been. SCSI can't even do hotplug devices _yet_. How would
we have debugged this stuff then?
And yes, USB belongs in the model, if for no other reason, that "it's a
bus and it has devices on it" :)
> *sigh*. halloween was a week ago.
Patches for this stuff are going to be happening for quite some time
now, don't despair.
And they are greatly appreciated, and welcomed from everyone :)
thanks,
greg k-h
>>>>> "Matthew" == Matthew Wilcox <[email protected]> writes:
Matthew> (i'm gagging to write an EISA subsystem ;-).
Humm, please don't... :-)
maz@midlife-crisis:~$ ls -R /sys/bus/eisa/
/sys/bus/eisa/:
devices drivers
/sys/bus/eisa/devices:
00:00 00:01 00:02
/sys/bus/eisa/drivers:
3c509
/sys/bus/eisa/drivers/3c509:
00:02
maz@midlife-crisis:~$
I have it working on x86 and Alpha, will test parisc and mips over the
week-end.
M.
--
Places change, faces change. Life is so very strange.