Re: sys/idtype.h unused enumeration values
Date:Tue, 19 May 2020 15:14:21 +0200 From:Kamil Rytarowski Message-ID: | I've abandoned the intention of changing these values (by adding | comments, renaming etc). Good, thank you. | Once I will have spare time I might look into | implementing the missing ID types, but I don't promise to do it soon. | P_PSETID is possibly the easiest one. That's an orthogonal issue - implementing some of them might be useful (perhaps) others less so, but whether ever implemented or not, their number in the ID space should be preserved. kre
Re: sys/idtype.h unused enumeration values
On 19.05.2020 15:06, Robert Elz wrote: > Date:Tue, 19 May 2020 14:12:31 +0200 > From:Kamil Rytarowski > Message-ID: <6874bb63-5146-797f-98b7-b9c497677...@gmx.com> > > | Rationale for pointless? > > There is no point. What more can I say? > > | My points were: > | > | - Clobbering OS that claims the goals of clean design and clean code > | with mutant alien bodies without counterparts in the native kernel, > | without request from any relevant standard body. > > Having the extra entries is harmless, there is no point deleting them. > I've abandoned the intention of changing these values (by adding comments, renaming etc). Once I will have spare time I might look into implementing the missing ID types, but I don't promise to do it soon. P_PSETID is possibly the easiest one. Thank you for the feedback. signature.asc Description: OpenPGP digital signature
Re: sys/idtype.h unused enumeration values
Date:Tue, 19 May 2020 14:12:31 +0200 From:Kamil Rytarowski Message-ID: <6874bb63-5146-797f-98b7-b9c497677...@gmx.com> | Rationale for pointless? There is no point. What more can I say? | My points were: | | - Clobbering OS that claims the goals of clean design and clean code | with mutant alien bodies without counterparts in the native kernel, | without request from any relevant standard body. Having the extra entries is harmless, there is no point deleting them. By all means, if you want, add a /* not implemented by NetBSD */ comment to each of the appropriate ones, but deleting them with the intent that they could (perhaps) be put back later is just making hard work - the values of anything that is actually used need to be preserved for ABI compat, if something occupies the slot of one of the ones to be replaced later, then the replacement has to be given a different value, making binary compat with other systems (emulations) much more complex. And all just to delete a meaningless line which is harming nothing... | - Collecting garbage in public headers that is unused, misleading and | can at best be dummy. So, mark it as unused/unimplemented, so it will no longer be misleading. Or replace them with placeholder symbols "was_P_..." if you'd like to detect at compile time code that might exist that won't work as intended. Just don't reuse the numeric values that the deleted symbols occupued. kre
Re: sys/idtype.h unused enumeration values
On 19.05.2020 08:38, Robert Elz wrote: > Date:Mon, 18 May 2020 21:11:36 +0200 > From:Kamil Rytarowski > Message-ID: <05255347-1c55-2762-aaf6-fec3caf48...@gmx.com> > > | Next, I can add my value at the end of list (and before _P_MAXIDTYPE). > > Other than this, everything that you propose is pointless. This one > you can do (assuming of course that there is a good reason for your new > entry, but there's no reason to doubt that now.) Rationale for pointless? My points were: - Clobbering OS that claims the goals of clean design and clean code with mutant alien bodies without counterparts in the native kernel, without request from any relevant standard body. - Collecting garbage in public headers that is unused, misleading and can at best be dummy. - Not know any public users. Extremely unlikely to have any private ones. But as there is insist on keeping that mutant clobber around as it formally leaked into ABI (even if very unlikely to have any single user ever), it's better to implement project identifiers and the other kernel components so this can be meaningful. > > kre > signature.asc Description: OpenPGP digital signature
