lkml.org 
[lkml]   [2015]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/2] make automatic device_id generation possible
From
On Thu, Mar 5, 2015 at 11:27 AM, Sergey Senozhatsky
<sergey.senozhatsky.work@gmail.com> wrote:
> On (03/05/15 11:04), Minchan Kim wrote:
>> > we upgraded our scripts but landed some bugs there? it's up to particular
>> > implementation. in your example, I assume, someone used zram with num_devices >= 1000?
>> > that's impossible. current num_devices limitation is 32. and uid-s start from 1000.
>>
>> I meant it.
>> If we support use-defined id and someone have used your idea so he can make zram
>> per-user as uid. After a while, new application stats automatic id assignment
>> so upcoming users can consume upcoming user id. yeah, automaic id will start
>> from 0 so it's very rare to reach 1000 but who knows?
>> My point is in your usecase, the script would be very fragile so it should
>> have second plan like automatic id.
>
> I don't see how it turns any script into a _necessarily fragile_ one
> here. there might be buggy scripts, yes. there might be no.
>
>> > these scripts should check if device has been created anyway, it just adds -EEXIST
>> > check. in general "what if user space does something wrong" thing can be beaten by
>> > "what if user space does everything right" argument. when script fails we just go
>> > and fix that script, I guess.
>>
>> Yes, I believe finally the script will go automatic id if it was broken.
>
> No, fixing a script does not imply at all switching to automatic device_id
> assignment mode.

If the script fix another way, not automatic id, it might be broken sometime
and they should find an another workaround. It will repeat forever, I guess.

Anyway, let's wait opinions from userland. Please involve them in this
thread rather than another channel.

Thanks, Sergey!

--
Kind regards,
Minchan Kim


\
 
 \ /
  Last update: 2015-03-05 04:01    [W:0.102 / U:21.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site