>The general rule is to locate drivers under drivers/, even the arch
>specific ones. This allows for easier grepping after users of a
>given API etc.
Ok, if that is a general rule I can move them (but the patch will
be large...). Generally we don't expect people to take attention
about CRIS when making changes but it is of course nice when it
happens.
>Smaller logical splitted patches, being sent out after each kernel release.
>This allows LKML readers to do peer review of changes to the IDE driver,
>without having to step over a lot of unrelated code.
Sure. More work for me but I'll also get more valuable feedback
and that is important.
/Mikael
On Mon, Jun 07, 2004 at 07:53:30AM +0200, Mikael Starvik wrote:
> >The general rule is to locate drivers under drivers/, even the arch
> >specific ones. This allows for easier grepping after users of a
> >given API etc.
>
> Ok, if that is a general rule I can move them (but the patch will
> be large...).
Please do so. As Bartlomiej note the rule is to keep drivers under:
drivers/<subsystem>/<arch>
The most efficient way to do the move is to send Linus a direct
mail with a simple shell script that does the moving of the files.
Along the lines of:
mkdir -p drivers/ide/cris
mv arch/cris/drivers/ide/* drivers/ide/cris
etc.
Sam
On Monday 07 of June 2004 20:43, Sam Ravnborg wrote:
> On Mon, Jun 07, 2004 at 07:53:30AM +0200, Mikael Starvik wrote:
> > >The general rule is to locate drivers under drivers/, even the arch
> > >specific ones. This allows for easier grepping after users of a
> > >given API etc.
> >
> > Ok, if that is a general rule I can move them (but the patch will
> > be large...).
>
> Please do so. As Bartlomiej note the rule is to keep drivers under:
> drivers/<subsystem>/<arch>
>
> The most efficient way to do the move is to send Linus a direct
> mail with a simple shell script that does the moving of the files.
> Along the lines of:
>
> mkdir -p drivers/ide/cris
> mv arch/cris/drivers/ide/* drivers/ide/cris
If you decide to do this please rename you driver
to i.e. ide_etrax100.c as we already have ide.c file. ;-)
[ BTW thanks for explaining e100_read_command usage,
I somehow overlooked that it is a variable not an enum ]
> etc.
>
> Sam