Re: [Wiki Edits: tmpfs, emacs, fcntl, and nice issues 1/4] removed the the pages that mentioned "nice" issues.

[Samuel Thibault]

Applied them all, thanks!

jbranso@dismail.de, le dim. 14 janv. 2024 21:33:43 -0500, a ecrit:
> Both issues have been fixed.
> 
> * open_issues/nice_changes_priority_of_parent_shell.mdwn: deleted
> * open_issues/nice_vs_mach_thread_priorities.mdwn: deleted
> * hurd/porting/system_api_limitations.mdwn: remove entry that said
>   "nice () doesn't work".
> ---
>  hurd/porting/system_api_limitations.mdwn      |   2 -
>  ...nice_changes_priority_of_parent_shell.mdwn |  15 -
>  .../nice_vs_mach_thread_priorities.mdwn       | 429 ------------------
>  3 files changed, 446 deletions(-)
>  delete mode 100644 open_issues/nice_changes_priority_of_parent_shell.mdwn
>  delete mode 100644 open_issues/nice_vs_mach_thread_priorities.mdwn
> 
> diff --git a/hurd/porting/system_api_limitations.mdwn 
> b/hurd/porting/system_api_limitations.mdwn
> index 1615ccc0..3ab4e406 100644
> --- a/hurd/porting/system_api_limitations.mdwn
> +++ b/hurd/porting/system_api_limitations.mdwn
> @@ -22,8 +22,6 @@ These are the known system API limits that have porting 
> implications.
>  
>  **_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_**
>  
> -**_[[nice() doesn't work|open_issues/nice_vs_mach_thread_priorities]]_**.
> -
>  **_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: 
> `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with 
> g++_**<br />**breaks:** fam, gail<br />**status:** maybe this should be in 
> [[PortingIssues]] (see _long_ bug log)
>  
>  **_[\#190367](http://bugs.debian.org/190367): libc0.3-dev: `fcntl` `F_GETLK` 
> not implemented (`ENOSYS`)_**<br />**breaks:** gnome-session (and others) 
> from running<br />**error:** misc lock-related errors
> diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn 
> b/open_issues/nice_changes_priority_of_parent_shell.mdwn
> deleted file mode 100644
> index a8a08f90..00000000
> --- a/open_issues/nice_changes_priority_of_parent_shell.mdwn
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
> -
> -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
> -id="license" text="Permission is granted to copy, distribute and/or modify 
> this
> -document under the terms of the GNU Free Documentation License, Version 1.2 
> or
> -any later version published by the Free Software Foundation; with no 
> Invariant
> -Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the 
> license
> -is included in the section entitled [[GNU Free Documentation
> -License|/fdl]]."]]"""]]
> -
> -[[!tag open_issue_gnumach open_issue_glibc]]
> -
> -  * [[!debbug 44039]]
> -
> -  * Also see [[nice_vs_mach_thread_priorities]].
> diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn 
> b/open_issues/nice_vs_mach_thread_priorities.mdwn
> deleted file mode 100644
> index 1f4c6ab8..00000000
> --- a/open_issues/nice_vs_mach_thread_priorities.mdwn
> +++ /dev/null
> @@ -1,429 +0,0 @@
> -[[!meta copyright="Copyright © 2010, 2012, 2013 Free Software Foundation,
> -Inc."]]
> -
> -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
> -id="license" text="Permission is granted to copy, distribute and/or modify 
> this
> -document under the terms of the GNU Free Documentation License, Version 1.2 
> or
> -any later version published by the Free Software Foundation; with no 
> Invariant
> -Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the 
> license
> -is included in the section entitled [[GNU Free Documentation
> -License|/fdl]]."]]"""]]
> -
> -[[!tag open_issue_gnumach open_issue_glibc]]
> -
> -This issue has been known for some time, due to coreutils' testsuite choking
> -when testing *nice*: [[!debbug 190581]].
> -
> -There has been older discussion about this, too, but this is not yet captured
> -here.
> -
> -
> -# IRC, freenode, #hurd, 2010-08
> -
> -    <pochu> I'm reading Mach and POSIX documentation to understand the 
> priorities/nice problems
> -    <pochu> antrik said it would be better to reimplement everything instead 
> of
> -      fixing the current Mach interfaces, though I'm not sure about that yet
> -    <youpi> uh, so he changed his mind?
> -    <pochu> it seems POSIX doesn't say nice values should be -20..20, but
> -      0..(2*NZERO - 1)
> -    <youpi> he said we could just change the max priority value and be done
> -      with it :)
> -    <pochu> so we can probably define NZERO to 16 to match the Mach range of
> -      0..31
> -    <youpi> s/said/had said previously/
> -    <antrik> youpi: POSIX is actually fucked up regarding the definition of
> -      nice values
> -    <antrik> or at least the version I checked was
> -    <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can 
> just
> -      set NZERO to 16 AFAICS:
> -      
> http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html
> -    <antrik> it talkes about NZERO and all; making it *look* like this could 
> be
> -      defined arbitrarily... but in other places, it's clear that the 
> standard
> -      40 level range is always assumed
> -    <antrik> anyways, I totally see no point in deviating from other systems 
> in
> -      this regard. it can only cause problems, and gives us no benefits
> -    <cfhammar> it says NZERO should be at least 20 iirc 
> -    <youpi> agreed
> -    <antrik> I don't remember the details; it's been a while since I looked 
> at
> -      this
> -    <antrik> youpi: changing the number of levels is only part of the
> -      issue. I'm not sure why I didn't mention it initially when we discussed
> -      this
> -    <antrik> youpi: I already concluded years ago that it's not possible to
> -      implement nice levels correctly with the current Mach interfaces in a
> -      sane fashion
> -    <antrik> (it's probably possible, but only with a stupid hack like 
> setting
> -      all the thread priorities one by one)
> -    <antrik> youpi: also, last time we discussed this, I checked how the nice
> -      stuff works currently on Hurd; and concluded that it's so utterly 
> broken,
> -      that there is no point in trying to preserve *any* compatibility. I 
> think
> -      we can safely throw away any handling that is alread there, and do it
> -      over from scratch in the most straightforward fashion
> -    <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly
> -      what you've just said to be a hack (setting all the thread priorities 
> one
> -      by one)
> -    <pochu> but there seems to be consensus that that's undesirable...
> -    <pochu> indeed, POSIX says NZERO should be at least 20
> -    <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the
> -      complexity of setting the thread max priorities individually
> -    <pochu> antrik: I don't. would it be too complex? I imagined it would be 
> a
> -      simple loop :)
> -    <antrik> pochu: in order to prevent race conditions, you have to stop all
> -      other threads before obtaining the list of threads, and continue them
> -      after setting the priority for each
> -    <antrik> I don't even know whether it can be done without interfering 
> with
> -      other thread handling... in which case it gets really really ugly
> -    <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing 
> the
> -      priority stuff as appropriate, and will change the tasks code later
> -    <antrik> it seems to me that using a more suitable kernel interface will
> -      not only be more elegant, but quite possibly actually easier to
> -      implement...
> -    <pochu> antrik: apparently it's not that hard to change the priority for
> -      all threads in a task, see task_priority() in gnumach/kern/task.c
> -    <pochu> it looks like the nice test failures are mostly because of the 
> not
> -      1:1 mapping between nice values and Mach priorities
> -    <marcusb> "Set priority of task; used only for newly created threads."
> -    <marcusb> there is a reason I didn't fix nice 8 years ago
> -    <marcusb> ah there is a change_threads option
> -    <pochu> marcusb: I'm not sure that comment is correct. that syscall is 
> used
> -      by setpriority()
> -    <marcusb> yeah
> -    <marcusb> I didn't read further, where it explains the change_threads
> -      options
> -    <marcusb> I was shooting before asking questions :)
> -    <marcusb> pochu: although there are some bad interactions if 
> max_priorities
> -      are set per thread
> -    <antrik> pochu: maybe we are talking past each other. my point was not 
> that
> -      it's hard to do in the kernel. I was just saying that it would be 
> painful
> -      to do from userspace with the current kernel interface
> -    <pochu> antrik: you could still use that interface in user space, 
> couldn't
> -      you? or maybe I'm misunderstanding...
> -    <pochu> cfhammar, antrik: current patch:
> -      http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably 
> what
> -      to do with high-priority threads. are there cases where there should 
> be a
> -      thread with a high priority but the task's priority shouldn't be high?
> -      e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c
> -    <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a
> -      higher priority, but then either we raise the task's max_priority if we
> -      need a high-prio thread, or we treat them specially (e.g. new field in
> -      struct thread), or maybe it's a non-issue because in such cases, all 
> the
> -      task is high-prio?
> -    <pochu> also I wonder whether I can kill the processor set's
> -      max_priority. It seems totally unused (I've checked gnumach, hurd and
> -      glibc)
> -    <pochu> (that would simplify the priority handling)
> -    <cfhammar> pochu: btw what does your patch do? i can't remember what was
> -      decided
> -    <pochu> cfhammar: it moves the max_priority from the thread to the task, 
> so
> -      raising/lowering it has effect on all of its threads
> -    <pochu> it also increases the number of run queues (and thus that of
> -      priority levels) from 32 to 40 so we can have a 1:1 mapping with nice
> -      values
> -    <pochu> cfhammar: btw don't do a full review yet, just a quick look would
> -      be fine for now
> -    <neal> why not do priorities from 0 to 159
> -    <neal> then both ranges can be scaled
> -    <neal> without loss of precision
> -    <pochu> neal: there would be from Mach to nice priorities, e.g. a task 
> with
> -      a priority of 2 another with 3 would have the same niceness, though 
> their
> -      priority isn't really the same
> -    <neal> pochu: sure
> -    <neal> pochu: but any posix priority would map to a current mach priority
> -      and back
> -    <neal> sorry, that's not true
> -    <neal> a posix priority would map to a new mach priority and bach
> -    <neal> and a current mach priority would map to a new mach priority and
> -      back
> -    <neal> which is I think more desirable than changing to 40 priority 
> levels
> -    <pochu> neal> and a current mach priority would map to a new mach 
> priority
> -      and back <- why should we care about this?
> -    <neal> to be compatible with existing mach code
> -    <neal> why gratutiously break existing interfaces?
> -    <pochu> they would break anyway, wouldn't them? i.e. if you do
> -      task_set_priority(..., 20), you can't know if the caller is assuming 
> old
> -      or new priorities (to leave it as 20 or as 100)
> -    <neal> you add a new interface
> -    <neal> you should avoid changing the semantics of existing interfaces as
> -      much as possible
> -    <pochu> ok, and deprecate the old ones I guess
> -    <neal> following that rule, priorities only break if someone does
> -      task_set_priority_new(..., X) and task_get_priority ()
> -    <neal> there are other users of Mach
> -    <neal> I'd add a configure check for the new interface
> -    <neal> alternatively, you can check at run time
> -    <pochu> well if you _set_priority_new(), you should _get_priority_new() 
> :)
> -    <neal> it's not always possible
> -    <pochu> other users of GNU Mach?
> -    <neal> you are assuming you have complete control of all the code
> -    <neal> this is usually not the case
> -    <neal> no, other users of Mach
> -    <neal> even apple didn't gratuitously break Mach
> -    <neal> in fact, it may make sense to see how apple handles this problem
> -    <pochu> hmm, I hadn't thought about that
> -    <pochu> the other thing I don't understand is: "I'd add a configure check
> -      for the new interface". a configure check where? in Mach's configure?
> -      that doesn't make sense to me
> -    <neal> any users of the interface
> -    <pochu> ok so in clients, e.g. glibc & hurd
> -    <neal> yes.
> -    <antrik> neal: I'm not sure we are winning anything by keeping
> -      compatibility with other users of Mach...
> -    <antrik> neal: we *know* that to make Hurd work really well, we have to 
> do
> -      major changes sooner or later. we can just as well start now IMHO
> -    <antrik> keeping compatibility just seems like extra effort without any
> -      benefit for us
> -    <guillem> just OOC have all other Mach forks, preserved full 
> compatibility?
> -    <neal> guillem: Darwin is pretty compatible, as I understand it
> -    <antrik> pochu: the fundamental approach of changing the task_priority
> -      interface to serve as a max priority, and to drop the notion of max
> -      priorities from threads, looks fine
> -    <antrik> pochu: I'm not sure about the thread priority handling
> -    <antrik> I don't know how thread priorities are supposed to work in 
> chreads
> -      and/or pthread
> -    <antrik> I can only *guess* that they assume a two-stage scheduling
> -      process, where the kernel first decides what process to run; and only
> -      later which thread in a process...
> -    <antrik> if that's indeed the case, I don't think it's even possible to
> -      implement with the current Mach scheduler
> -    <antrik> I guess we could work with relative thread priorities if we 
> really
> -      want: always have the highest-priority thread run with the task's max
> -      priority, and lower the priorities of the other threads accordingly
> -    <antrik> however, before engaging into this, I think you should better
> -      check whether any of the code in Hurd or glibc actually uses thread
> -      priorities at all. my guess is that it doesn't
> -    <antrik> I think we could get away with stubbing out thread priority
> -      handling alltogether for now, and just use the task priority for all
> -      threads
> -    <antrik> I agree BTW that it would be useful to check how Darwin handles
> -      this
> -    <pochu> btw do you know where to download the OS X kernel source? I found
> -      something called xnu, but I?m not sure that's it
> -    <antrik> pochu: yeah, that's it
> -    <antrik> Darwin is the UNIX core of OS X, and Xnu is the actual kernel...
> -    <pochu> hmm, so they have both a task.priority and a task.max_priority
> -    <neal> pochu: thoughts?
> -    <pochu> neal: they have a priority and a max_priority in the task and in
> -      the threads, new threads inherit it from its parent task
> -    <pochu> then they have a task_priority(task, priority, max_priority) that
> -      can change a task's priorities, and it also changes it for all its
> -      threads
> -    <neal> how does the global run queue work?
> -    <pochu> and they have 128 run queues, no idea if there's a special reason
> -      for that number
> -    <pochu> neal: sorry, what do you mean?
> -    <neal> I don't understand the point of the max_priority parameter
> -    <pochu> neal: and I don't understand the point of the (base) priority ;)
> -    <pochu> the max_priority is just that, the maximum priority of a thread,
> -      which can be lowered, but can't exceed the max one
> -    <pochu> the (base) priority, I don't understand what it does, though I
> -      haven't looked too hard. maybe it's the one a thread starts at, and 
> must
> -      be <= max_priority
> -    <antrik> pochu: it's clearly documented in the manual, as well as in the
> -      code your initial patch changes...
> -    <antrik> or do you mean the meaning is different in Darwin?...
> -    <pochu> I was speaking of Darwin, though maybe it's the same as you say
> -    <antrik> I would assume it's the same. I don't think there would be any
> -      point in having the base vs. max priority distinction at all, except to
> -      stay in line with standard Mach...
> -    <antrik> at least I can't see a point in the base priority semantics for
> -      use in POSIX systems...
> -    <pochu> right, it would make sense to always have priority == 
> max_priority
> -      ...
> -    <pochu> neal: so max_priority is that maximum priority, and priority is 
> the
> -      one used to calculate the scheduled priority, and can be raised and
> -      lowered by the user without giving special permissions as long as he
> -      doesn't raise it above max_priority
> -    <pochu> well this would allow a user to lower a process' priority, and
> -      raise it again later, though that may not be allowed by POSIX, so then 
> we
> -      would want to have max_priority == priority (or get rid of one of them 
> if
> -      possible and backwards compatible)
> -    <antrik> pochu: right, that's what I think too
> -    <antrik> BTW, did I bring up handling of thread priorities? I know that I
> -      meant to, but I don't remember whether I actually did...
> -    <pochu> antrik: you told me it'd be ok to just get rid of them for now
> -    <pochu> so I'm more thinking of fixing max_priority and (base) priority 
> and
> -      leaving thread's scheduling priority as it currently is
> -    <pochu> s/so/though/
> -    <antrik> pochu: well, my fear is that keeping the thread priority 
> handling
> -      as ist while changing task priority handling would complicate the
> -      changes, while giving us no real benefit...
> -    <antrik> though looking at what Darwin did there should give you an idea
> -      what it involves exactly...
> -    <pochu> antrik: what would you propose, keeping sched_priority ==
> -      max_priority ?
> -    <pochu> s/keeping/making/
> -    <antrik> yes, if that means what I think it does ;-)
> -    <antrik> and keeping the priority of all threads equal to the task 
> priority
> -      for now
> -    <antrik> of course this only makes sense if changing it like this is
> -      actually simpler than extending the current handling...
> -    <antrik> again, I can't judge this without actually knowing the code in
> -      question. looking at Darwin should give you an idea...
> -    <pochu> I think leaving it as is, making it work with the task's
> -      max_priority changes would be easier
> -    <antrik> perhaps I'm totally overestimating the amount of changes 
> required
> -      to do what Darwin does
> -    <antrik> OTOH, carrying around dead code isn't exactly helping the
> -      maintainability and efficiency of gnumach...
> -    <antrik> so I'm a bit ambivalent on this
> -    <antrik> should we go for minimal changes here, or use this occasion to
> -      simplify things?...
> -    <antrik> I guess it would be good to bring this up on the ML
> -    <cfhammar> in the context of gsoc i'd say minimal changes
> -    <pochu> there's also neal's point on keeping backwards compatibility as
> -      much as possible
> -    <neal> my point was not backwards compatibility at all costs
> -    <antrik> I'm still not convinced this is a valid point :-)
> -    <neal> but to not gratutiously break things
> -    <antrik> neal: well, I never suggested breaking things just because we
> -      can... I only suggested breaking things to make the code and interface
> -      simpler :-)
> -    <antrik> I do not insist on it though
> -    <neal> at that time, we did not know how Mac did it
> -    <antrik> I only think it would be good to get into a habit that Mach
> -      interfaces are not sacred...
> -    <neal> and, I also had a proposal, which I think is not difficult to
> -      implement given the existing patch
> -    <antrik> but as I said, I do not feel strongly about this. if people feel
> -      more confident about a minimal change, I'm fine with that :-)
> -    <antrik> neal: err... IIRC your proposal was only about the number of 
> nice
> -      levels? we are discussing the interface change necessary to implement
> -      POSIX semantics properly
> -    <antrik> or am I misremembering?
> -    <pochu> antrik: he argues that with that number of nice levels, we could
> -      keep backwards compatibility for the 0..31 levels, and for 0..39 for
> -      POSIX compatibility
> -    <antrik> pochu: yes, I remember that part
> -    <neal> antrik : My suggestion was: raise the number of nice levels to 160
> -      and introduce a new interface which uses those.  Adjust the old 
> interface
> -      to space by 160/32
> -    <antrik> neal: I think I said it before: the problem is not *only* in the
> -      number of priority levels. the semantics are also wrong. which is why
> -      Darwin added a max_priority for tasks
> -    <neal> what do you mean the semantics are wrong?
> -    <neal> I apologize if you already explained this.
> -    <antrik> hm... I explained it at some point, but I guess you were not
> -      present at that conversation
> -    <neal> I got disconnected recently so I likely don't have it in backlog.
> -    <antrik> in POSIX, any process can lower its priority; while only
> -      privileged processes can raise it
> -    <antrik> Mach distinguishes between "current" and "max" priority for
> -      threads: "max" behaves like POSIX; while "current" can be raised or
> -      lowered at will, as long as it stays below "max"
> -    <antrik> for tasks, there is only a "current" priority
> -    <antrik> (which applies to newly created threads, and optionally can be 
> set
> -      for all current threads while changing the task priority)
> -    <antrik> glibc currently uses the existing task priorities, which leads 
> to
> -      *completely* broken semantics
> -    <antrik> instead, we need something like a max task priority -- which is
> -      exactly what Darwin added
> -    <neal> yes
> -    <antrik> (the "current" task priority is useless for POSIX semantics as 
> far
> -      as I can tell; and regarding thread priorities, I doubt we actually use
> -      them at all?...)
> -    <cfhammar> where does a new thread get its initial max_priority from?
> -    <antrik> cfhammar: from the creator thread IIRC
> -    <pochu> yes
> -
> -
> -## IRC, freenode, #hurd, 2010-08-12
> -
> -    <pochu> my plan is to change the number of priority levels and the
> -      threads/tasks priority handling, then add new RPCs to play with them 
> and
> -      make the old ones stay compatible, then make glibc use the new RPCs
> -
> -
> -# IRC, freenode, #hurd, 2012-12-29
> -
> -    <braunr> and, for a reason that i can't understand, there are less
> -      priorities than nice levels, despite the fact mach was designed to run
> -      unix systems on top of it ..
> -    <youpi> btw, didn't we have a plan to increase that number?
> -    <braunr> i have no idea
> -    <braunr> but we should :)
> -    <youpi> I remember some discussion about it on the list
> -
> -
> -## IRC, freenode, #hurd, 2012-12-31
> -
> -    <youpi> braunr: btw, we *do* have fixed the nice granularity
> -    <youpi> +#define MACH_PRIORITY_TO_NICE(prio) ((prio) - 20)
> -    <youpi> in the debian package at least
> -    <youpi> ah, no
> -    <youpi> it's not applied yet
> -    <youpi> so I have the patch under hand, just not applied :)
> -    <braunr> but that's a simple shift
> -    <braunr> the real problem is that there aren't as many mach priorities as
> -      there are nice levels
> -    <youpi> that's not really a problem
> -    <youpi> we can raise that in the kernel
> -    <youpi> the problem is the change from shifted to unshifted
> -    <youpi> that brings odd nice values during the upgrade
> -    <braunr> ok
> -    <braunr> i hope the scheduler code isn't allergic to more priorities :)
> -
> -
> -## IRC, freenode, #hurd, 2013-01-02
> -
> -    <braunr> pochu: i see you were working on nice levels and scheduling code
> -      some time ago
> -    <braunr> pochu: anything new since then ?
> -    <pochu> braunr: nope
> -    <braunr> pochu: were you preparing it for the gsoc ?
> -    <pochu> braunr: can't remember right now, either that or to fix a ftbfs 
> in
> -      debian
> -    <youpi> iirc it's coreutils which wants proper nice levels
> -
> -
> -# IRC, OFTC, #debian-hurd, 2013-03-04
> -
> -    <Steap> Is it not possible to set the priority of a process to 1 ?
> -    <Steap> these macros:
> -    <Steap> #define MACH_PRIORITY_TO_NICE(prio) (2 * ((prio) - 12))
> -    <Steap> #define NICE_TO_MACH_PRIORITY(nice) (12 + ((nice) / 2))
> -    <Steap> are used in the setpriority() implementation of Hurd
> -    <Steap> so setting a process' priority to 1 is just like setting it to 0
> -    <youpi> Steap: that has already been discussed to drop the *2
> -    <youpi> the issue is mach not supporting enough sched levels
> -    <youpi> can be fixed, of course
> -    <youpi> just nobody did yet
> -
> -GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit
> -6fe36b76f7983ec9a2e8a70420e431d54252442e).
> -
> -
> -## IRC, OFTC, #debian-hurd, 2013-03-07
> -
> -    <braunr> youpi: btw, why did you increase the number of priorites to 50 ?
> -    <youpi> for the nice levels
> -    <braunr> and probably something more, there are only 40 nice levels
> -    <youpi> yes, the current computation leaves some margin
> -    <youpi> so I preferred to keep a margin too
> -    <braunr> ok
> -    <youpi> e.g. for the idle thread, etc.
> -    <braunr> or interrupt threads
> -    <youpi> yep
> -    <braunr> i see the point, thanks
> -    <tschwinge> Is the number of 40 specified by POSIX (or whatever) or is 
> that
> -      a Linuxism?
> -    <braunr> good question
> -    <braunr> posix is weird when it comes to such old unixisms
> -    <braunr> there is a NZERO value, but i don't remember how it's specified
> -    <youpi> it's at least 20
> -    <tschwinge> (I don't object to the change; just wondered.  And if 
> practice,
> -      you probably wouldn't really need more than a handful.  But if that
> -      change (plus some follow-up in glibc (?) improves something while not
> -      adding a lot of overhead, then that's entirely fine, of course.)
> -    <braunr> "A maximum nice value of 2*{NZERO}-1 and a minimum nice value 
> of 0
> -      shall be imposed by the system"
> -    <braunr> NZERO being 20 by default
> -    <youpi> and 20 is the minimum for NZERO too
> -    <braunr> hm, not the default, the minimul
> -    <braunr> minimum
> -    <braunr> yes that's it
> -    <braunr> ok so it's actually well specified
> -    <tschwinge> Aha, I see (just read it, too).  So before that change we
> -      simply couldn't satisfy the POSIX requirement of (minimum) NZERO = 20,
> -      and allowing for step-1 increments.  Alright.
> -    <youpi> yep
> -    <youpi> thus failing in coreutils testsuite
> -- 
> 2.43.0
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.