| Re: [PATCH v6 02/10] ipc: "use key as id" functionality for resource get system ca [message #48374 is a reply to message #48367] |
Tue, 16 October 2012 07:52   |
Stanislav Kinsbursky
Messages: 683
Registered: October 2011
|
Senior Member |
|
|
15.10.2012 23:39, Eric W. Biederman пишет:
> Stanislav Kinsbursky <skinsbursky@parallels.com> writes:
>
>> This patch introduces new IPC resource get request flag IPC_PRESET, which
>> should be interpreted as a request to try to allocate IPC slot with number,
>> starting from value resented by key. IOW, kernel will try
>> allocate new segment in specified slot.
>>
>> Note: if desired slot is not emply, then next free slot will be used.
>
> This way of handling things is pretty nasty.
>
> - You don't fail if the requested id is not available.
It's a part of design. Consider IPC_PRESET as an advice.
It's up to user to check, does returned id suits it's needs.
> - You don't allow assigning the key (which leads to the need to change
> the key in later patches). Changing the creator uid and creator
> gid and key is semantically ugly.
>
Key assigning ability is implemented in 4-6'th patches of the series.
Changing creator uid and creator gid with key can be dropped. The reason why I
added this was to give more abilities to syscall caller.
> It would be much cleaner if you could instead add IPC_PRESET and then
> extend the definition of the creation functions all by one argument.
>
> aka
> int msgget(key_t key, int msgflg, int id);
> int semget(key_t key, int nsems, int semflg, int id);
> int shmget(key_t key, size_t size, int shmflg, int id);
>
> Where the extra id argument is ignored unless IPC_PRESET is specified.
>
This way suits my needs. The reason, why I didn't this that way was trying to
affect user-space API as less, as possible.
So, if there will be more votes for adding one more argument to existent systems
calls - I'll do it.
> Also msgget, semget, and shmget should fail if unregconized flags are
> passed in. That ipcget doesn't do that today is bizarre.
>
This looks like another issue, which can be fixed separately.
> Eric
>
--
Best regards,
Stanislav Kinsbursky
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
