linux-kernel - Re: [PATCHSET pata-2.6] ide: rq->buffer, data, special and misc cleanups

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:	Mon, 13 Apr 2009 17:22:01 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	jeff@...zik.org
Cc:	fujita.tomonori@....ntt.co.jp, bharrosh@...asas.com, tj@...nel.org,
	petkovbb@...il.com, bzolnier@...il.com,
	linux-kernel@...r.kernel.org, axboe@...nel.dk,
	linux-ide@...r.kernel.org
Subject: Re: [PATCHSET pata-2.6] ide: rq->buffer, data, special and misc
	cleanups

On Mon, 13 Apr 2009 03:54:38 -0400
Jeff Garzik <jeff@...zik.org> wrote:

> FUJITA Tomonori wrote:
> > On Tue, 31 Mar 2009 16:04:39 +0300
> > Boaz Harrosh <bharrosh@...asas.com> wrote:
> > 
> >>> I
> >>> just don't think bvec should be used outside of block/fs interface.
> >>> As I wrote before, non-FS users have no reason to worry about bio.
> >>> All it should think about is the requst it needs to issue and the
> >>> memory area it's gonna use as in/out buffers.  bio just doesn't have a
> >>> place there.
> >>>
> >> I don't understand what happens to all the people that start to work on the block
> >> layer, they start getting defensive about bio being private to the request
> >> level. But the Genie is out of the bag already (I know cats and bottles).
> >> bio is already heavily used above the block layer from directly inside filesystems
> >> to all kind of raid engines, DM MD managers, multi paths, integrity information ...
> >>
> >> Because bio is exactly that Ideal page carrier you are talking about.
> > 
> > Wrong. multi path doesn't use bio. md accesses to the bio internal
> > (it's not nice) and has the own way to carry pages. dm has the own
> > mechanism on the top of bio. And bio doesn't work nicely for file
> > systems such as btrfs, which handle multiple devices.
> > 
> > Please stop your wrong argument 'bio is the ideal page carrier'.
> 
> What is the multi-device problem with bio?

Well, if it works nicely, I guess that we don't have something like
drivers/dm/{dm-bio-record.h, dm-bio-list.h}, btrfs_multi_bio struct,
or md's own page carrier?


> The idea behind bio is to be the ideal page carrier :)  It sounds like 
> bio needs revision, not abandonment.

I think that bio was designed to be an ideal page carrier for file
systems. But it's ideal not for everyone. I don't think that Boaz's
argument to use bio everywhere such as under drivers/scsi is a good
idea.

Yeah, a structure for page carrier needs revision anyway. At least, we
need to unify the way (or code) to handle multiple devices.
--
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/