linux-kernel - Re: [PATCHv3] UBI: new module ubiblk: block layer on top of UBI

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, 25 Aug 2011 10:06:44 +0300
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	david.wagner@...e-electrons.com,
	linux-mtd <linux-mtd@...ts.infradead.org>,
	linux-embedded <linux-embedded@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Tim Bird <tim.bird@...sony.com>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCHv3] UBI: new module ubiblk: block layer on top of UBI

Hi Arnd,

On Wed, 2011-08-24 at 18:23 +0200, Arnd Bergmann wrote:
> That should  be fine, yes. I would probably put them into the same
> header file though if they are in the same number space even
> when you use them on distinct devices.
> 
> It does feel a little clumsy to have yet another character device
> to manage the block devices though. What do you think about one
> of these alternative approaches:
> 
> * When the ubi block device driver gets loaded, create one block
>   device per volume and let the user deal with permissions for
>   the devices instead of having to first create them as well.

I think this wasteful. Why should I have block devices which I do not
need? If I have 4 UBI volumes, and need only one ubiblk, why should I
waste my resources for 3 more of them (e.g., I do not want to waste
memory for struct inode for each sysfs entry which these useless block
devices will add). Also, will this mean 3 more block devices registered?

I think it is much uglier to have 3 "dummy" block devices and confuse
users than have one nice control character device. For the sake of not
having a separate control chardev?

> * Use the existing UBI control device for the block devices as
>   well and just add two more ioctls to create the devices.
>   You can add a logical bus_type for this so that the ubi block
>   driver gets automatically loaded matched with the device when
>   one is created using the control device.

This sounds  better IMHO, but I am still not sure that adding another
dummy bus and exposing it in sysfs and more complexity in the ubiblk
code is more elegant and less wasteful than just creating a separate
chardev...

-- 
Best Regards,
Artem Bityutskiy

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