entally
an architecture-dependent notion.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
on-disk change.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
gs).
How many of those "real bugs" exist only because C11 gave compilers new
latitude to produce unexpected code?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
s broken. I see changes of
this sort as defense against broken disks if nothing else.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
nic:
mount -o onerror=panic /dev/wd2a /builds
Of course, actually making that work, well, I don't have any
suggestions for cat-bellers. Unless and until I have a significant
amount of spare time, it's all just "it might be nice if".
/~\ The ASCII Mo
- the post says
it can't be unmounted, but blames umount, not unmount, so it's not
clear to me whether that's userland's fault or not.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
ve more or less the same issue with every other non-free
inode in the filesystem? The only thing I can see that's special about
the root inode in this regard is that it is the only inode that is used
immediately upon mount.
/~\ The ASCII Mouse
\ / Ribbon Campaign
comes time to put real data at that spot in the
file, a block will be available. Which block it is is not important.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
mount process very unuseful.
No, of course not. I doubt anyone thinks that would be a good idea. I
would not expect that checking to happen until the inode in question
actually gets used.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@ro
~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
different. To be better.
Except, of course, that (I assume) you don't think it _would_ be
better.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
as possible, rather than to allocate
maximum-sized buffers, whose total size will be as big as possible?
I'm presumably missing something here, but what?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email!
ne) NULL
have both historically been perfectly good null pointer constants.
Also...syntax error? Really? _Syntax_ error?? I'd really like to see
what they've done to the grammar to lead to that; I'm having trouble
imagining how that would be done.
/~\ The ASCII Mouse
\ /
e near anything
security/safety-sensitive I'm using.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
compiler(s). (Well, unless
you consider the language to be the problem because it's possible to
implement it badly. I don't.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4
teger will necessarily produce a zero integer.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
e verbose wording, saying
explicitly that the 0 to which the control expression is compared is,
when applicable, a null pointer constant. (Comparison of a pointer
with a null pointer constant is specifically permitted for == and != -
see 6.5.9.)
/~\ The ASCII Mouse
\ / Ribbo
f an intermediate cast to unsigned long; size_t may be
wider than unsigned long, though admittedly it's unlikely offsetof()
will need to return a value greater than the largest unsigned long).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
ht affect this; I'm talking
strictly about C99 here.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
with a suitable #include, NULL, _is_ a null pointer
constant.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
behaviour, so I'm going to transform it into
something I know damn well you didn't expect".
> RUST is better defined that C and is indeed used in OS development
> these days
...so? I don't see how this is related to the rest of the discussion.
/~\ The ASCII Mouse
\
o work around "bugs" created by language
committees deciding to give compilers new latitutde to "optimize"
meaningful code into trash.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email!
other one, and one that doesn't require the complete rewrite
a switch as drastic as C->rust would: various compilers (including
older versions of the gcc family) that don't think it reasonable to
take clear code and language-lawyer it into broken executables.
/~\ The ASCII
it, is up on ftp.rodents-montreal.org in
/mouse/misc/nb8.0 under the name mwi_acpi-config (that's not what I
called it when using it; I called it INSTALLER, but that's a pretty
meaningless name for the FTP area).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Ag
cpiwmi driver, you don't include any driver
> for acpiwmibus, so the acpiwmi driver is useless to you.
I'm not sure whether the right fix is to drop acpiwmi or add back
acpiec or acpiecdt, so...what _is_ acpiwmi?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Aga
scattered all over the tree
sounds like a recipe for serious headaches.
If and when it looks worth the effort, I can always back out the
removal commit and clean up the result. But SCM_MEMORY looks like the
more valuable thing for my use cases for the moment.
/~\ The ASCII M
it does in the kernel?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
bad idea; if it breaks the user's
ktrace, I think it is a moderately bad idea. (I haven't had to ktrace
make very often, but when I have there hasn't been much else that would
be suitable.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-mon
The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
ossible ways to keep it
from happening.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
want to do the above, great. I'll be happy to help
to the extent that I'm competent to. But that is unlikely to include
dealing with the rump side of it.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email!
coexist
with user-initiated ktracing, which doesn't sound likely in view of
what you said.
So I still call it a bad idea. For what that's worth.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8
; 3, I have the (maybe false?)
impression that it involves at least a few pay-to-play "standards".
Oh, and 4, it's far more of a moving target than I'd like.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email!
try this on someone else's production
machine. I have numerous other changes in my kernels, but none that I
would _expect_ to have any bearing on this.
The test program is on ftp.rodents-montreal.org in
/mouse/misc/unfdstress.c. It did compile for me on 8.0 (I test-built
it, though I didn't run
d to printed complaints.
Could I possibly get you to ktrace it or some such to find out what's
making it die? (Warning, unless it exits very soon after startup, it
will probably produce a lot of ktrace data.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML
usly - see busy_a() and busy_b().
Interestingly, I have since tested it on (mutant) 4.0.1 and it works
just fine, even under stress. I can't as test it on 1.4T because the
program is written to the broken CMSG_* API, which 1.4T predates.
/~\ The ASCII Mouse
\ / Ri
t.)
In the tree I'm using at work, I've just thrown printfs into
usbd_new_device. But that's a bit ugly, probably not the best approach
(though I can certainly send a diff for what I have if anyone wants).
Thoughts?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HT
't know. But the answer is to fix the problem, not to
twist the code into a pretzel to work around the compiler's refusal to
be suitable for the job.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
now, that
seems like an investment of my time with a low expected return.)
Comments? Thoughts? If there is something else that this depends on
that I haven't mentioned, just let me know.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo
ant API calls to get the same effect.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
provide a replacement
for the "halted, press any key to reboot" message. This has worked
fine for build.sh build runs. But this build.sh release run failed
release ===> etc (with: DISTRIBUTION_DONE=1)
[...]
#create XEN3_DOM0/machdep.d
CC=/home/mouse/amd64/OBJDIR/tooldir.NetBSD-5.2-a
I wrote about build.sh release failing. Someone (again off-list)
pointed out that I didn't really give enough information. And, this
time, the change is small.
So, here is the changeset in question:
commit e1f85bf071f6fcc167b5266da1db35c3ee9a8969
Author: Mouse
Date: Wed Oct 17 13:17:47 2018
h among the #includes, and the only files in all of
/usr/src that include the string "cpureset_delay" are
sys/arch/amd64/amd64/machdep.c and sys/arch/i386/i386/machdep.c, so I
have no idea what makes config generate opt_cpureset_delay.h.
I clearly need to dig deeper.
/~\ The ASCII
T4V/Pw2ndjkjrChsKswcqoLJJpmExJOrqdRFFgHw6L6XWjB2ZSNqBTTXyPHJYMI=
(While I recognize you may not be the person to say this to, denying
access like that without any indication of what the problem is or whom
to ask for help is...singularly useless.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against H
c files). Alternatively, and maybe preferably, a failure
in rump should not fail a build, at least not unless such failures were
specifically requested.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email!
de your day's amusement... :->
And I suppose to be fair I should try - should have tried -
webmas...@www.fixup.fi before maundering about not saying whom to
contact.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Em
ime, or what?
In particular, would any special action need to be taken upon adding a
new ioctl for it to be recognized?
What about collisions, two ioctls having the same numeric value? (I'm
not aware of any offhand, but I'd be astonished if it never happened.)
/~\ The ASCII
ong the
lines of "this fd accepted FOO_IOC_A, so we're going to decode this one
as FOO_IOC_B rather than BAR_IOC_C".
I suppose that's the hazard of catchall interfaces like ioctl(): they
are difficult to make usefully discoverable.
/~\ The ASCII Mouse
\ / Rib
't any
way to prevent that, nor to prevent them from conflicting when - and
eventually it will happen - someone wants to run a system with both new
thing and other thing.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montre
timestamp glitch. It
appears to be something wrong with rump and its reaction to a kernel
change - see below.
In each case, the build was done as me, a nonprivileged user, using
(cd /usr/src && sh ./build.sh -D /home/mouse/amd64/DESTDIR -O
/home/mouse/amd64/OBJDIR -x -U build)
with stdout an
build
running. Hasn't failed so far, but it hasn't been long enough for that
to mean much yet.
Is this documented anywhere?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
, in
/mouse/misc/7300/2020-04-28-1/7300a.c, 7300a.h, and 7300a-reg.h (the
other version I've moved into .../misc/7300/2020-04-23-1/).
Priorities have changed at work and I'm now on a different subtask of
this job. I expect to be back on this one before long, though; I'm
going to be trying to rewrite
re - and my
thanks, again, to everyone who took time and brain cycles to help me
with this.
I just feel really really stupid that it's taken me multiple months to
remember that the hardware even _has_ that register and realize that it
could be relevant.
/~\ The ASCII Mo
an compensate for the API differences in a glue layer in
userland. But I don't yet know whether that will help with this delay
issue I'm seeing.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
t, because I didn't overtly respond to it. I
probably should have said something like "Got it!" there.
And, I think this too I didn't say, but thank you very much - you and
everyone who's contributed - for taking the time and effort to help me
with this!
/~\ The ASCII
I've understood your question correctly, that's a "yes".
Of course, some aspects of this are likely to be hardware-specific; I
daresay not all hardware can notice monitor connect/disconnect. Heck,
there's probably hardware out there that can't even fetch DDC info from
the monitor
/
event isn't sent upon monitor connect or
disconnect, at least not in the case of my test machine, but is instead
delayed until some (other) client queries state - but there is no need
to define a new event or a new event-carrying mechanism or any of that.
/~\ The ASCII
direction, but READ is when CPU reads
> data provided by the device.
Yes: READ corresponds to read() and WRITE to write(). One of the
things that confuses me is that I have no write-direction DMA going on
at all; all the DMA is in the read direction. But there is a driver
write to the buffer that
think it might
be a good idea to comment the code a little more; the only comment I
see in bouyer@'s original patch is a what/how comment, replicated for a
total of three instances, not a why comment, and I think a why comment
or two might not be amiss.)
/~\ The ASCII Mouse
\
ds fixing too; I've seen enough things that don't mess with decoding
enables before checking for decode width)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E
ce never tries to read the contents, since the update
> must be flushed from the cache to DRAM or you may end up reading
> stale data later.
So I have to treat it like a DMA write even if there is never any
write-direction DMA actually going on?
Then the problem *probably* is not bus_dma b
-to-volatile.
I can go into more detail if desired, even up to sending the whole
driver (it's for a commercial product, but all the secret sauce is in
userland - I got permission long ago to open-source the kernel stuff).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X A
h I think ought to work.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
spect, do, and if there _is_ something else the CPU could usefully be
doing, I suspect spending the (scarce) cycles there is preferable.
At least for most systems. There certainly is a place for allowing the
admin to insist on encrypted swap even on slow machines.
/~\ The ASCII
done about it. Thoughts?
Mouse
g that assembly code with C (or, more precisely, the associated
potential window spilling) would have a significant impact on
performance at higher sample rates.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email!
10, the .h, 2005).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
s on that spectrum.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
.
>> please leave it alone.
> It's been deprecated since -7, we can remove it for -10.
So? I still agree with mrg: I too see no benefit to removing it (or
for that matter to deprecating it). What am I missing? What benefit
do you see?
/~\ The ASCII
of who's accessing it).
Personally, I've wanted it as a way to provide an out-of-band channel
to userland programs (like a control command channel for various
daemons), but...hmm.
Feels strange to find an idea I like coming from Linux.
/~\ The ASCII Mouse
\ / Ribbon Ca
happy with. (I rather
wish I'd saved some of them as test cases, but I didn't.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
ie, until there are no outstanding children, until the ECHILD return
is accurate). That's important for some use cases.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
se
{ printf("wait error: %s\n",strerror(errno));
}
}
else
{ printf("child %d reaped\n",dead);
}
}
printf("parent exiting\n");
return(0);
}
> "signals are a semantic cesspool"
That they are.
/~\ The ASCII
vour of file descriptor,
akin to kevent or timerfd descriptors. I have no doubt it could be
done one way or another. But arguably it's best to just use SIGCHLD
and a loop that uses WNOHANG.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@r
rly boot code and I don't recall anything that would
make it difficult.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Is this a case where -R helps?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
ode is important only for what it teaches you.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
disadvantage that
>> they decrease responsiveness [...].
> Yes, of coure.
If that's "of course" to you, you're not a _complete_ newbie. :-)
I'd say, just use the simple loop. Once you have that much working,
*then* worry about things like handling (pseudo-)hardware failures or
interr
way to see if any explanation might be
forthcoming.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
n C is just not really safe without [the braces].
Is C *ever* safe? (Safe from what?)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
...etc
}
}
}
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
have
made up something plausible but entirely fictitious, or gone and dug up
an example of a long else-if chain in real code somewhere.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
\ Email!7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
never seen this done, but on some
buses it certainly could be done). You wrote of "the other 7 bits",
indicating that you are thinking of the register as 8 bits wide, but
you used bus_space_read_4, so there is an apparent mismatch. I don't
know enough about your setup to tell whether it's an ac
k of it, the value is incorrect often
enough for those asserts to fire, so anything depending on it is
already broken.
Good point.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
ories
in their path which your line says they shouldn't.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
mapreg_debug = 0;
...
}
(in the implementation of pci_mapreg_map)
int mapreg_debug = 0;
...
if (mapreg_debug) printf("...", ...);
It's a horrible thing to do for "permanent" (production) code, but I
see nothing at all wrong with it for expe
lementation for that port. Your driver just needs to know "is this
a (PCI) I/O space mapping or a (PCI) memory space mapping?", and
sometimes not even that; what it turns into at the machine-code level
is hidden by the bus_space layer. See pci_mapreg_type(),
pci_mapreg_map(), etc.
each turns on PCI debugging code. The difference is that
with what I sketched, the debugging code it turns on is code you add,
whereas the debugging code pci_conf_debug turns on is code that's
already there (though code you add can of course be controlled by
anything you want, including pci_conf_de
hether the bug matters in practice.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
t" as it is "sysadmin" and "non-sysadmin" - which is also part
of why it's significantly harder to find exceptions in /usr/bin than in
/usr/sbin, since "root commands" is closer to being a subset of
"sysadmin commands" than the other way around.
/~\
s small as in this example I find that formatting to
be the overall best. But it flies in the face of all sorts of rules.
That sort of judgement call is a hallmark of an AI-complete problem.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
ll I
have on the most convenient scratch hardware), and neither
"kill -STOP 1" nor "kill -KILL 1" had any effect visible to ps ax. I
don't know where/how they're getting stopped, but they are.
Mouse
ult action of "do nothing".
The wording in wait(2) is, I believe, talking about only the SIG_IGN
kind of ignoring.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
actly once per signal. (Unless a single child
changed state twice, such as by being stopped and then killed, in which
case the implementation had better queue wait stati as well or you'll
be calling wait too often!)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against H
death handling, and then someone (POSIX maybe?)
decided it would be good to include all of both mechanisms.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
e system I tried it on.
I'll be poking around a bit more.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
in some form (a fourth process,
maybe?).
As far as I can tell, reparenting currently is limited to (1) init
inheriting orphans and (2) sharply limited partial reparenting due to
ptrace().
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo
playing, I'd
expect the same thing to happen. In that state, the driver isn't going
to be changing anything, so plugging headphones in then might help you
identify whether it's a software issue or not.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML
401 - 500 of 812 matches
Mail list logo
