Re: wait(2) and SIGCHLD
On Sat, Aug 15, 2020 at 07:57:26PM -0400, Terry Moore wrote: > >> I would say so, especially since that would mean the child's parent is > >> no longer the process that forked it (which could break other use > >> cases). > > > > That depends on how you implement detaching, but I suppose ultimately > > it's important for getppid() to revert to 1 at the point the parent > > exits (neither before, nor after, nor never) so some kind of linkage > > needs to remain. > > > > Bah. > > > > I guess it's time to invent yet another different interface to > > fork-and-really-detach. > > No time to experiment today, but from the descriptions it sounds as if a > double fork would work, > with the child exiting immediately after forking the grandchild? Kind of > unpleasant, but nothing > new needed? (For the record: yes, forking twice works, that's more or less the standard approach; but it's comparatively expensive.) -- David A. Holland dholl...@netbsd.org
Re: fsck updating but not fixing filesystem
On Fri, Aug 28, 2020 at 12:02:09PM -, Christos Zoulas wrote: > David Holland wrote: > > > Sounds like there is an in interesting fuzzing project in there for > > > someone - make a filesystem mage and the repeatedly damage it, then > > > see if fsck can fix it, then if you get a rump panic when moving > > > everything around, and then re-run fsck to see if it indicates any new > > > issues :) > > > > One can do that, but given that there are lots of edge cases and many > > of them will be hard to reach, formal verification might be more > > effective. > > I think we should fix all filesystems to pass: > > https://www.netbsd.org/~riastradh/tmp/dirconc.c > > Then we can think about formal verification :-) You know I wrote the original version of that, right? :-) -- David A. Holland dholl...@netbsd.org
Re: patch for am7930 audio
>>> By the way, I'm not so familiar to sparc. >>> audioamd(4) has many assembly code (though they look very old stuff). >> [...] I see no assembly code in arch/sparc/dev/audioamd* on 5.2 [...] > It's in sparc/sparc/amd7930intr.s. Ah! Personally, I would be inclined to preserve that. It handles the interrupt entirely in the trap window, which, for something that interrupts frequently, can significantly lessen the impact of the interrupts on performance. Isaki-san did not give any indication what motivated the removal of that assembly (and presumably its replacement with C), but I would hesitate to do it without, at the very least, measuring the performance impact of such a change. Yes, code sharing is good - other things being equal. I suspect, though I haven't measured it either, that "other things" are *not* equal here, that replacing 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! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: patch for am7930 audio
> > By the way, I'm not so familiar to sparc. > > audioamd(4) has many assembly code (though they look very old stuff). > > For what it's worth...I don't know what "very old" means to you, but I > see no assembly code in arch/sparc/dev/audioamd* on 5.2 (the .c > datestamped 2010, the .h, 2005). It's in sparc/sparc/amd7930intr.s. --- Izumi Tsutsui
Re: patch for am7930 audio
> By the way, I'm not so familiar to sparc. > audioamd(4) has many assembly code (though they look very old stuff). For what it's worth...I don't know what "very old" means to you, but I see no assembly code in arch/sparc/dev/audioamd* on 5.2 (the .c datestamped 2010, 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
patch for am7930 audio
I have improved am7930 family audio drivers to share more code among
them: audioamd(4) on sparc, vsaudio(4) on vax, and bba(4).
The patch is: http://www.netbsd.org/~isaki/20200904-am7930.diff
vsaudio(4) and bba(4) were tested by naru@, tsutsui@. Both worked
fine. (thanks!)
By the way, I'm not so familiar to sparc.
audioamd(4) has many assembly code (though they look very old stuff).
Is there any (historical or traditional) reason why I should not
remove these?
Summary of this patch:
- Remove complex and useless callbacks: onopen, onclose, and
indirect_{read,write}. This makes audioamd(4) and vsaudio(4) almost
the same.
- Remove all assembly code for audioamd(4).
- trigger_* method (as pseudo DMA) is more suitable for this device.
Thanks,
---
Tetsuya Isaki
