tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: sys/idtype.h unused enumeration values



On 18.05.2020 21:31, Taylor R Campbell wrote:
>> Date: Mon, 18 May 2020 21:11:36 +0200
>> From: Kamil Rytarowski <n54%gmx.com@localhost>
>>
>> On 18.05.2020 20:24, Robert Elz wrote:
>>>     Date:        Mon, 18 May 2020 19:45:55 +0200
>>>     From:        Kamil Rytarowski <n54%gmx.com@localhost>
>>>     Message-ID:  <ad8e44bb-3778-67ad-6c6d-7ce0681bebbb%gmx.com@localhost>
>>>
>>>   | I have got a local use-case for another P_type (premature to discuss it
>>>   | in this thread) and I would rather recycle an unused value.
>>>
>>> Don't do that, it is just a number, use one that hasn't been used
>>> for this purpose before.
>>>
>>>   | Do we plan to get Solaris feature-parity with all the types? I assume
>>>   | that the answer is NO. If so, can we delete the P_ values that are not
>>>   | applicable for NetBSD?
>>>
>>> I have no problem with that - just don't reuse the values for some
>>> different purpose, keep them reserved (assign them meaningless reserved
>>> names) just in case there's ever a need to implement one of those things
>>> (this is very very cheap insurance).
>>
>> I propose to delete P_CID and recycle its place for P_PSETID.
> 
> There are 2,147,483,630 different numbers you can choose from, if I
> counted right -- that's over two billion.  It's not that important to
> be economical with reuse when there's a scary comment above it
> exhorting you not to mess with the existing numbers...  Also, P_PSETID
> already appears to be assigned the number 15, so why would you want to
> change that?
> 

If I delete P_TASKID ... P_P_CPUID ones, P_SETID will be reordered (but
we can force the number anyway). If I delete P_CID there is an inelegant
hole. Naturally P_SETID -> P_CID can fill the gap.

This is in theory ABI change, but no users could use in a useful
approach previously.

My intention isto g/c unused values and keep this clean and elegant (as
this is still possible).

Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index