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
| ||
|
Date: Thu, 16 Apr 2015 08:40:34 +0900 From: Minchan Kim <minchan@...nel.org> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>, Nitin Gupta <ngupta@...are.org>, linux-kernel@...r.kernel.org, Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> Subject: Re: [PATCHv3 0/8] introduce dynamic device creation/removal On Wed, Apr 15, 2015 at 02:37:17PM -0700, Andrew Morton wrote: > On Tue, 3 Mar 2015 21:49:42 +0900 Sergey Senozhatsky <sergey.senozhatsky@...il.com> wrote: > > > Hello, > > > > This patchset introduces zram-control sysfs class, which has two sysfs > > attrs: > > - zram_add -- add a new specific (device_id) zram device > > - zram_remove -- remove a specific (device_id) zram device > > This patchset and the "make automatic device_id generation possible" > still appear to have quite a few unresolved issues. So I'm holding > them out of the 4.1 merge window. There is no unresolved issue to me. Only one thing I suspect was the feature user enforce new device id for dynamic device addition and we finally decided to remove the function because there was no useful usecase at this point. Sergey and other userland people agreed that so Sergey sent a patch [zram: do not let user enforce new device dev_id] https://lkml.org/lkml/2015/3/6/427 So, I'm happy with that. Acutally, I wanted to resend whole patchset for dynamic device creation/remove patchset with corrected version (ie, remove user enforce new device id) to avoid confusion but didn't said it to Sergey. It was my bad. Sergey, Could you resend this patchset without user's enforce device id function based on new -rc1? > > Unfortunately these were the first-arriving zram patches, so the later > ones required quite a bit of mangling. Hopefully I got it all right. > > This was all a bit disruptive. Please let's not leave major patchsets > floating about in an incomplete/unresolved state for week after week? I will keep it in mind. Thanks. -- Kind regards, Minchan Kim -- 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