Hello IDE people,
I'd like to get input from everyone involved in drivers/ide/ on the
current development process.
I would like to know what code is kept in sync between 2.4/2.5
(2.2/2.0?). This way I can start by understanding what is already being
done. This is related to the recent "hdparm and removable IDE?" thread
on LKML.
I would like to start by declaring ide_hwifs[] static, and removing the
extern ide_hwifs from ide.h. all references to ide_hwifs[] will be
converted to macros and/or access method functions, that return a
pointer to a particular ide_hwifs_t. for_each_hwif() and replacements
for whatever else is in use will be provided as well, initially just
doing the same thing that is done now, ie iterating through ide_hwifs[].
There's more to my plan, that's just to get the discussion going. I
will only address what can be easily merged into all currently supported
kernel trees, I just need to know what they are.
by creating a new file ide-kernel.[ch], and moving the ide_hwifs[] and
accessor functions to it, each kernel tree can implement it differently
without complicating backports for the common stuff. Initially the
changes will *not* alter any behaviour, just jockeying stuff into place
to make that painless when the time comes. (think about it: if the
access methods return pointers, who's going to notice when ide_hwifs[]
is replaced with a linked list?)
My motivation: I'd *really* like to be able to sell entry level PC
servers with hotswap raid1. I'm not in a hurry, baby steps are ok, I
just want to get the ball rolling. It's all negotiable. I'm no expert
here.
Regards,
Jeremy
--
Jeremy Jackson <[email protected]>
Hey,
On 29 Mar 2003, Jeremy Jackson wrote:
> Hello IDE people,
>
> I'd like to get input from everyone involved in drivers/ide/ on the
> current development process.
>
> I would like to know what code is kept in sync between 2.4/2.5
> (2.2/2.0?). This way I can start by understanding what is already being
> done. This is related to the recent "hdparm and removable IDE?" thread
> on LKML.
>
> I would like to start by declaring ide_hwifs[] static, and removing the
> extern ide_hwifs from ide.h. all references to ide_hwifs[] will be
> converted to macros and/or access method functions, that return a
> pointer to a particular ide_hwifs_t. for_each_hwif() and replacements
> for whatever else is in use will be provided as well, initially just
> doing the same thing that is done now, ie iterating through ide_hwifs[].
Yes, I've been thinking about this recently and I think this is the way to
go.
> There's more to my plan, that's just to get the discussion going. I
> will only address what can be easily merged into all currently supported
> kernel trees, I just need to know what they are.
If it will be merged any time soon you may call yourself lucky :-).
> by creating a new file ide-kernel.[ch], and moving the ide_hwifs[] and
> accessor functions to it, each kernel tree can implement it differently
> without complicating backports for the common stuff. Initially the
> changes will *not* alter any behaviour, just jockeying stuff into place
You should just commit changes to 2.5 and later port it to 2.4.
> to make that painless when the time comes. (think about it: if the
> access methods return pointers, who's going to notice when ide_hwifs[]
> is replaced with a linked list?)
Yep, but probably there will be some problems in transition.
> My motivation: I'd *really* like to be able to sell entry level PC
> servers with hotswap raid1. I'm not in a hurry, baby steps are ok, I
> just want to get the ball rolling. It's all negotiable. I'm no expert
> here.
>
> Regards,
>
> Jeremy
> --
> Jeremy Jackson <[email protected]>
Regards
--
Bartlomiej Zolnierkiewicz
Bart,
When you do, let me know.
I would like to suggest how to decouple the hwgroup in general but not
lose it because of a need to sync the iops during setup and hba recovery.
The dirt on why it has to be done is not public per NDA's, but this will
help the driver. Additionally, movement to create hwif->queue for
load-balance and threading of the channel IO is a must now. As SATA
arrives in bulk, their will be more effective hwif's per hba and the
rules for assignment must change.
Cheers,
On Sat, 29 Mar 2003, Bartlomiej Zolnierkiewicz wrote:
>
> Hey,
>
> On 29 Mar 2003, Jeremy Jackson wrote:
>
> > Hello IDE people,
> >
> > I'd like to get input from everyone involved in drivers/ide/ on the
> > current development process.
> >
> > I would like to know what code is kept in sync between 2.4/2.5
> > (2.2/2.0?). This way I can start by understanding what is already being
> > done. This is related to the recent "hdparm and removable IDE?" thread
> > on LKML.
> >
> > I would like to start by declaring ide_hwifs[] static, and removing the
> > extern ide_hwifs from ide.h. all references to ide_hwifs[] will be
> > converted to macros and/or access method functions, that return a
> > pointer to a particular ide_hwifs_t. for_each_hwif() and replacements
> > for whatever else is in use will be provided as well, initially just
> > doing the same thing that is done now, ie iterating through ide_hwifs[].
>
> Yes, I've been thinking about this recently and I think this is the way to
> go.
>
> > There's more to my plan, that's just to get the discussion going. I
> > will only address what can be easily merged into all currently supported
> > kernel trees, I just need to know what they are.
>
> If it will be merged any time soon you may call yourself lucky :-).
>
> > by creating a new file ide-kernel.[ch], and moving the ide_hwifs[] and
> > accessor functions to it, each kernel tree can implement it differently
> > without complicating backports for the common stuff. Initially the
> > changes will *not* alter any behaviour, just jockeying stuff into place
>
> You should just commit changes to 2.5 and later port it to 2.4.
>
> > to make that painless when the time comes. (think about it: if the
> > access methods return pointers, who's going to notice when ide_hwifs[]
> > is replaced with a linked list?)
>
> Yep, but probably there will be some problems in transition.
>
> > My motivation: I'd *really* like to be able to sell entry level PC
> > servers with hotswap raid1. I'm not in a hurry, baby steps are ok, I
> > just want to get the ball rolling. It's all negotiable. I'm no expert
> > here.
> >
> > Regards,
> >
> > Jeremy
> > --
> > Jeremy Jackson <[email protected]>
>
> Regards
> --
> Bartlomiej Zolnierkiewicz
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
LAD Storage Consulting Group
On Sat, 2003-03-29 at 16:28, Jeremy Jackson wrote:
> I would like to know what code is kept in sync between 2.4/2.5
> (2.2/2.0?). This way I can start by understanding what is already being
> done. This is related to the recent "hdparm and removable IDE?" thread
> on LKML.
None of it.
> I would like to start by declaring ide_hwifs[] static, and removing the
> extern ide_hwifs from ide.h. all references to ide_hwifs[] will be
> converted to macros and/or access method functions, that return a
Feel free, its your tree. If it cleans up stuff a lot it may be a
workable change for 2.5. Don't overdo the access function stuff though
our you'll make things slower and larger.
Alan