linux-kernel - Re: [RFC PATCH] ide-floppy: use rq->cmd for preparing and sending packet cmds to the drive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080213124625.GB13446@gollum.tnic>
Date:	Wed, 13 Feb 2008 13:46:25 +0100
From:	Borislav Petkov <petkovbb@...glemail.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [RFC PATCH] ide-floppy: use rq->cmd for preparing and sending
	packet cmds to the drive

On Tue, Feb 12, 2008 at 10:39:22PM +0100, Bartlomiej Zolnierkiewicz wrote:

Hi Bart,

> I think that this _really_ should be done _after_ unifying ATAPI handling [*].
> Otherwise you will be making some of the same changes to the _three_ copies
> of (more or less) identical code and more importantly we will have to delay
> unification after _all_ drivers are converted to rq->cmd[] (+ lets not forget
> that I'll have more changes to review ;).
> 
> (*) please take a closer look at *_issue_pc(), *_transfer_pc() and *_pc_intr()
>     in ide-{floppy,tape,scsi} (the useful hint is that after making these
>     functions free of references to device driver specific objects/functions
>     we can use drive->media == ide_{floppy,tape,scsi} checks for handling
>     not yet fully unified / media type specific code).

I started working on probably the easiest unification we could do: unify all the
pc->flags defines and move them in a header where all drivers can use them. This
raises an architectural design question: The way i see it, the generic ATAPI handling
is going to be sort of "serving" functionality to the drivers using ATAPI. Do we want
all this functionality to go to ide.{h,c} or we want specific atapi.{h,c} files that
contain only this unified functionality, or whatever else. In general, how is this
generic layer going to be distributed among headers/.c files and what do we want there?

/me tends to think that special headers/files, small and easy to manage and
modular, have more advantages in this case but this is just me. After we've
decided on that, the rest of the issues will resolve by themselves/get easier to
tackle.

Thanks.

-- 
Regards/Gruß,
    Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/