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:	Tue, 5 Aug 2014 09:07:16 +0200
From:	Karel Zak <kzak@...hat.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Sami Kerola <kerolasa@....fi>, util-linux@...r.kernel.org,
	Timofey Titovets <nefelim4ag@...il.com>,
	Nitin Gupta <ngupta@...are.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: zram: device management utility needed

On Tue, Aug 05, 2014 at 11:00:24AM +0900, Minchan Kim wrote:
> On Wed, Jul 30, 2014 at 12:14:42AM +0100, Sami Kerola wrote:
> > The zram devices are not created by any sort of equipment appearing in a
> > bus so an method of creating new or removing existing devices will be
> > needed.  When the zram module is loaded it should create
> > /dev/zram-control device, that responds to ioctl() calls[4].  The calls
> > could be similar with /dev/loop-control[5], that allow adding or removing
> > specified device, and discover adding a free device.
> 
> Normally, dynamic management is good to have, I think but I didn't hear
> strong requirement for that until now.

I guess that number of zram devices will be always relatively small
compare to /dev/loopN devices. It is not unusual that people use
systems with more than 256 loop devs, so /dev/loop-control makes a lot
of sense to keep the device management effective and simple.

> Why don't you change num_device param at module loading time?

If you have really many loopN devices than create all the nodes at
boot time means extra overhead (allocate nodes in kernel, events to
udev, create /dev files etc.).  The ioctl LOOP_CTL_* API also provides
LOOP_CTL_GET_FREE that returns unused device, so you don't have to
scan all the /dev/loopN devices to detect a free device.

> I'd like to hear real scenario from whom are about to using that faeture
> right now and what's the problem with num_device param.

Again, I don't think it's so important for zram as for loop devices.
All depends how people will use zram devices. We will see...

    Karel

-- 
 Karel Zak  <kzak@...hat.com>
 http://karelzak.blogspot.com
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ