linux-kernel - Re: [PATCH 7/7] sg_ring: convert core ATA code to sg

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]

Date:	Thu, 27 Dec 2007 13:21:39 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	Jens Axboe <jens.axboe@...cle.com>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [PATCH 7/7] sg_ring: convert core ATA code to sg_ring.

Hello, Rusty.

Rusty Russell wrote:
> On Wednesday 26 December 2007 19:36:36 Tejun Heo wrote:
>> It would be better to build upon sg chaining as we already have it.  I
>> think it can be made much easier with a bit more safe guards,
>> generalization and some helpers.
> 
>     I did this work to replace sg chaining.  The current chaining code gives 
> us longer sgs, and (if used carefully) the ability to append in some 
> circumstances.  But it's clumsy, and we can do better.  This is my attempt.

Ah.. okay.  That makes sense then.  I fully agree that sg chaining as it
currently stands is pretty ugly to use.  Appending extra entries
requires reserving one extra space in the sg list to be appended to
accommodate the last entry of the original list, which will be used for
chaining now.  Also, it's quite brittle in that information can get out
of sync easily (there's no one API for sg list manipulation, things have
to be done manually).

>     I understand that people are experiencing whiplash from the idea of 
> another change just after the sg chaining changes which have already gone in.  
> 
>     At the very least, I think I'll have to come up with a better transition 
> plan for SCSI drivers, rather than trying to convert them all at once... In 
> theory, sg chaining can be done through the sg ring arrays, but that's pretty 
> horrible.

I don't necessarily think large one time conversion is bad.  They're
necessary at times and make sense when they can increase long term
maintainability of the code.  One thing I'm concerned about is the
mixture of sg chaining and sg ring.  It would be best if we can agree on
conversion plan (or sg chaining extension plan).

Thanks.

-- 
tejun
--
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/