On Fri, Apr 05, 2024 at 06:48:05AM +, David Holland wrote:
>- read or write errors on memory mapped files result in SIGSEGV,
> which is annoying to deal with and does actually turn up in the
> field sometimes (*);
Oops, looks like I forgot to populate the asterisk.
On Wed, Apr 03, 2024 at 05:40:47PM +, Ice Cream wrote:
> I'm trying to speed up sort(1) by using mmap(2) instead of temp
> files.
>
> ftmp() (see code below) is called in the sort functions to create and
> return a temp file. mkstemp() is used to create the temp file, then
> the file
On Sun, Dec 31, 2023 at 02:54:50AM +0100, Johnny Billquist wrote:
> Ok. I oversimplified.
>
> If I remember right, the point was that something sub 200ms is perceived by
> the brain as being "instananeous" response. It don't mean that one cannot
> discern shorter times, just that from an
On Sat, Dec 30, 2023 at 10:44:52PM +, Taylor R Campbell wrote:
> Note: I am NOT proposing any substantive changes to the implementation
> of the allocator -- I'm just proposing that we go back to the old
> _interface_, using the new pool-cache-based _implementation_, and to
> add
On Thu, Aug 03, 2023 at 03:03:06PM +0930, Brett Lymn wrote:
> > If anyone cares about veriexec(4) and would like to volunteer to take
> > this on, we can discuss what needs to be done and how to proceed.
>
> I will take this on since I was originally responsible for the mess. It
> does play
On Tue, Jul 18, 2023 at 09:32:42PM -0700, Jason Thorpe wrote:
> > Don't cloner instances differ in minor number? If not, shouldn't they?
>
> Not that I?m aware of. They result in a new file object with a new
> private data pointer, but they don?t change the minor number and I
> don?t see
On Tue, Jul 18, 2023 at 03:25:02PM -0700, Jason Thorpe wrote:
> That *might* work in this particular case, but it would not work
> for e.g. a cloning device where you get additional descriptors via
> dup() or whatever.
Don't cloner instances differ in minor number? If not, shouldn't they?
--
On Wed, May 10, 2023 at 01:08:27AM +, Taylor R Campbell wrote:
> I propose to add new config_*_acquire/release functions:
> dev = config_found_acquire(...);
> ...
> config_detach_release(dev);
Seems reasonable...
(note, haven't read the diff carefully yet)
--
David A. Holland
On Wed, May 10, 2023 at 10:11:31AM +, Taylor R Campbell wrote:
> > > (In general, erroring in I/O is a whole additional can of worms; it's
> > > wrong to not report back however much work happened before the error
> > > when it can't be undone, but also impossible to both report work and
>
On Tue, May 09, 2023 at 09:21:38PM +, Taylor R Campbell wrote:
> I propose adding uiopeek(buf, n, uio) and uioskip(n, uio) which
> together are equivalent to successful uiomove(buf, n, uio).
>
> This allows a driver to separately:
> 1. transfer data into a buffer (uiopeek) first, and
On Mon, May 08, 2023 at 12:36:21AM +, David Holland wrote:
> I... completely failed to recognize it as an emoji and assumed it was
> supposed to be -9 to forcibly shut something down.
emoji. smiley. yeah
--
David A. Holland
dholl...@netbsd.org
On Mon, May 08, 2023 at 02:09:07AM +0200, Johnny Billquist wrote:
> > > not nearly as
> > > horrible as, say, the hack I once implemented where calling
> > > wait4(0x456d756c,(int *)0x61746f72,0x4d616769,(struct rusage
> > > *)0x633a2d29)
> >
On Fri, May 05, 2023 at 09:44:25PM -0400, Mouse wrote:
> >>> But I kind of think it'd be preferable to make a way to clone a
> >>> second independent struct file for the same socket than to start
> >>> mucking with per-descriptor state.
> >> [...] it should be easy to extend dup3() to make
On Thu, May 04, 2023 at 08:40:49AM -0400, Mouse wrote:
> >> I can't think of any at all; to begin with it's limited to forks
> >> that don't exec
> [...]
>
> Well, except for libraries that open fds internally, without exposing
> them to the calling code. Depending on the user case, they
On Sun, Apr 30, 2023 at 10:50:51PM +0700, Robert Elz wrote:
> Date:Sun, 30 Apr 2023 05:25:41 +
> From: David Holland
> Message-ID:
>
> | Close-on-fork is apparently either coming or already here, not sure
> | which, but it's a
On Sun, Apr 30, 2023 at 09:44:49AM -0400, Mouse wrote:
> > Close-on-fork is apparently either coming or already here, not sure
> > which, but it's also per-descriptor.
>
> I should probably add that here, then, though use cases will likely be
> rare. I can think of only one program I wrote
On Sun, Apr 30, 2023 at 12:49:03AM -0400, Mouse wrote:
> This is pushing towards making it per-descriptor state. At present,
> the versions I have don't have anything but close-on-exec as true
> per-descriptor state. A quick look at 9.1 and cvsweb.netbsd.org
> (which, mirabilu visu, actually
On Sun, Mar 19, 2023 at 01:49:54PM +0700, Robert Elz wrote:
> | Except they aren't. They're on open file table entries, something
> | remarkably difficult to describe in a way that doesn't just refer to
> | the kernel-internal mechanism behind it
>
> Yes. The terminology in this area
On Mon, Feb 06, 2023 at 09:19:26PM -0500, Mouse wrote:
> Perhaps the simplest is
>
> dd if=/dev/urandom bs=65536 of=/dev/mem
>
> but there are others.
>
> Yet I can't help feeling that there is some sense in which it *is* fair
> to say that userland should never be able to crash the
On Sun, Dec 25, 2022 at 10:27:49AM -0500, Mouse wrote:
> >> According to that PDF, dholland is wrong.
> > I fail to see a behaviour that would be allowed due to dholland@'s
> > definition, but not according to the one you cited, nor the other way
> > round.
>
> A read returning the pre-TRIM
On Mon, Dec 12, 2022 at 11:53:56PM +1100, matthew green wrote:
> maybe port that tool back, it's also supposed to match the
> linux command of the same name. it's not in netbsd-9, but
> last i tried, the interfaces the -current tool uses are
> available in -9 kernels.
The trim/discard
On Thu, Dec 08, 2022 at 11:44:59PM -0500, Mouse wrote:
> Since the data on the device is still there afterwards, I don't think
> [...]
The state of the data after TRIM is unspecified; you might read the
old data, you might read zeros or ones, you might (I think) even read
something else.
What
On Sun, Oct 16, 2022 at 06:31:55AM +1100, matthew green wrote:
> note that it is already used in libpcap, bind, libuv, and as a
> test for xlint, in our tree, for consumed components.
hmm?
% grep 'pragma.*once' /usr/include/**.h
%
also, while it does appear (once) inside libuv, that's within
On Sat, Oct 15, 2022 at 07:21:35PM +, Taylor R Campbell wrote:
> [bcc tech-userlevel tech-toolchain, followups on tech-kern]
>
> Traditionally to avoid problems with repeated inclusion of a header
> file, you put #include guards around it, say in sys/dev/foo.h:
>
> #ifndef
On Fri, Sep 23, 2022 at 05:34:26PM -0400, David H. Gutteridge wrote:
> It's not just O_NONBLOCK that can be expected/desired, vte wants to set
> O_CLOEXEC as well. The Linux kernel accepts and applies both of those
> flags in a posix_openpt(3) call.
There should be no path through open(2)
On Mon, Sep 26, 2022 at 11:53:46PM +, Emmanuel Dreyfus wrote:
> > > I will try to figure it out, since its not yet implemented the syscall
> > > is a
> > > good way to start dev in BSD kernel.
> >
> > I'm not sure about that; many people have started looking at it and
> > not got
On Mon, Sep 26, 2022 at 06:15:23PM +0200, Patryk wrote:
> I will try to figure it out, since its not yet implemented the syscall is a
> good way to start dev in BSD kernel.
I'm not sure about that; many people have started looking at it and
not got anywhere.
--
David A. Holland
On Fri, Sep 23, 2022 at 01:39:16PM +0200, Martin Husemann wrote:
> > Then, shouldn't the open(2) (and posix_openpt(3)) at least fail with
> > EINVAL or something if other flags are specified?
>
> The man page says:
>
> Note that unlike implementations on some other operating systems,
On Fri, Sep 16, 2022 at 07:00:23PM +0700, Robert Elz wrote:
> That is, except for in pkgsrc, which is why I still
> have a (very mild) concern about that one - it actually compares the
> version numbers using its (until it gets changed) "Dewey" comparison
> routines, and for those, 9.99.100 is
On Mon, Aug 08, 2022 at 07:18:05AM -0700, Paul Goyette wrote:
> (personal note)
> It really seems to me that the current module sub-systems is at
> best a second-class capability. I often get the feeling that
> others don't really care about modules, until it's the only way
> to provide
On Tue, Jul 12, 2022 at 09:57:20AM -0400, Mouse wrote:
> > a. Define the source-level API in a way that is detached from the
> >C language.
>
> This can be done, but only by attaching it to some other language
> instead. It doesn't even make sense to talk about an API without it
On Mon, Jul 11, 2022 at 08:45:09PM -0700, Jakob Stoklund Olesen wrote:
> I saw this project on the wiki, and it reminds me of a problem I have
> been trying to understand better:
> https://wiki.netbsd.org/projects/project/language-neutral-interfaces/
>
> [...] This means I have to think
On Tue, Jun 14, 2022 at 07:59:33PM +0200, Johnny Billquist wrote:
> > What might be interesting is a way to influence the order in which
> > processes are chosen to kill...
>
> I don't see any realistic way of doing anything with that.
> It's basically the first process that tries to
On Mon, Jun 06, 2022 at 02:40:29PM +0200, Gerhard Sittig wrote:
> There is no problem with that I assume. From personal experience
> I can tell that git takes some getting used to. But once you do
> you don't want to go back. Seriously.
Every time I have to use the damn thing, I want to go
On Thu, Mar 24, 2022 at 11:16:58PM -0400, Mouse wrote:
> > The conclusion over the past ~25 years has been that there isn't;
> > qsort and things like it work "well enough" and real uses for
> > closures that really motivate the feature come up rarely enough that
> > it doesn't happen.
>
>
On Tue, Mar 22, 2022 at 09:16:36PM -0400, Mouse wrote:
> Indeed, you can have different sizes for pointers to different object
> types, too. I _think_ pointers to different function types can have
> different sizes, but I'm less certain of that. (There would be little
> point, since all
On Thu, Mar 10, 2022 at 11:10:13AM +0100, Jos? Bollo wrote:
> What I have in mind is that there is no need for a specific IDL: the
> language itself is the IDL and the code generator.
>
> I can add that SCHEME interpreters are small piece of code (that you
> don't have to change, pick it and
On Mon, Feb 14, 2022 at 08:11:57AM +, Taylor R Campbell wrote:
> > On Fri, Feb 11, 2022 at 01:33:04PM +, Taylor R Campbell wrote:
> > > membar_enter is currently documented to be a store-before-load/store
> > > barrier: https://man.netbsd.org/NetBSD-9.2/membar_ops.3
> > >
> > >
(sorry, lost track of this)
On Mon, Feb 14, 2022 at 05:12:13AM +0100, Joerg Sonnenberger wrote:
> Am Mon, Feb 14, 2022 at 02:45:46AM + schrieb David Holland:
> > On Mon, Feb 14, 2022 at 03:12:29AM +0100, Joerg Sonnenberger wrote:
> > > Am Mon, Feb 14, 2022 at 02:01:
On Mon, Feb 14, 2022 at 03:12:29AM +0100, Joerg Sonnenberger wrote:
> Am Mon, Feb 14, 2022 at 02:01:13AM + schrieb David Holland:
> > In this case I would argue that the names should be membar_load_any()
> > and membar_any_store().
>
> Kind of like wi
On Fri, Feb 11, 2022 at 01:33:04PM +, Taylor R Campbell wrote:
> membar_enter is currently documented to be a store-before-load/store
> barrier: https://man.netbsd.org/NetBSD-9.2/membar_ops.3
>
> membar_enter()
>Any store preceding membar_enter() will happen before all
On Tue, Jan 11, 2022 at 11:10:24AM +0100, Manuel Bouyer wrote:
> The attached diff changes the procfs behavior to match the linux one, for
> linux processes:
> comore:/home/bouyer>ls -l /proc/self/fd/
> total 1
> crw--w 1 bouyer tty5, 0 Jan 11 11:08 0
> crw--w 1 bouyer tty
On Sat, Jan 08, 2022 at 12:28:52PM -0800, Paul Goyette wrote:
> > Count me in as well - the name completion collision has always annoyed me.
>
> +2 :-)
--
David A. Holland
dholl...@netbsd.org
On Mon, Sep 20, 2021 at 09:03:12PM +, Taylor R Campbell wrote:
> > In any case, here is a diff that adds the argument structure type
> > checking. I also added an awk program to generate the argument
> > structures and all of the call binding stuff automatically from an
> > interface
On Sun, Sep 19, 2021 at 07:43:32AM -0700, Jason Thorpe wrote:
> >> | else plumbs it through either, but I'll go ahead and do so.
> >>
> >> Please do. What other things don't permit fcntl() to work? We
> >> should fix any of those.
> >
> > Well, I?ll fix these 2 anyway.
>
> ?and
On Sat, Sep 11, 2021 at 03:43:24PM -0700, Jason Thorpe wrote:
> The basic idea involves the device call mechanism I introduced a while ago.
You still haven't explained why that needs to be untyped and based on
uncheckable string constants.
--
David A. Holland
dholl...@netbsd.org
On Sun, Aug 15, 2021 at 09:10:48AM -0700, Jason Thorpe wrote:
> > Why do we pass untyped strings around with this device_call mechanism?
> > Was there any discussion about this beforehand? Had I known it was
> > proposed I would have objected to an untyped string method calling
> > mechanism
On Wed, Aug 04, 2021 at 05:52:46PM -0700, Jason Thorpe wrote:
> Old example:
>
> c->c_dev = config_found(sc->sc_dev, , pciprint,
> CFARG_SUBMATCH, config_stdsubmatch,
> CFARG_LOCATORS, locs,
> CFARG_DEVHANDLE,
On Thu, Jul 15, 2021 at 11:00:36AM -0700, Chuck Silvers wrote:
> setting an extattr on a device node in UFS is already disallowed.
> ffs_setextattr() has this check:
>
> if (ap->a_vp->v_type == VCHR || ap->a_vp->v_type == VBLK)
> return (EOPNOTSUPP);
>
> I have not
On Thu, Jul 15, 2021 at 06:26:55PM +0200, Rhialto wrote:
> > Seems to me the best/safest thing to do for now would be to prohibit
> > the extended-attr on devices and fifos.
>
> If I have a normal file system, and in a directory is an entry with an
> inode for a fifo (or a device), and I set
I noticed that there was a loose function ffsext_strategy lying
around, mentioned it to Christos, and he committed this:
> Modified Files:
> src/sys/ufs/ffs: ffs_vnops.c
>
> Log Message:
> Hook up ffsext_strategy to fifos. Pointed out by dholland@
which is well and good (actually it
On Mon, Jul 12, 2021 at 08:03:54AM +, Emmanuel Dreyfus wrote:
> On Fri, Jul 09, 2021 at 08:52:08PM +0000, David Holland wrote:
> > This was discussed somewhere briefly (probably on chat) a couple weeks
> > ago, with the conclusion that we should just make the limit something
On Fri, Jul 09, 2021 at 03:27:57PM +, Emmanuel Dreyfus wrote:
> I recently hit a bug where mariadb import failed befause of
> maxlocksperuid limit:a
> http://mail-index.netbsd.org/netbsd-users/2021/07/09/msg027330.html
>
> Attached is a patch that documents ENOMEM for fcntl() and
On Tue, Jun 29, 2021 at 05:07:10AM -, Christos Zoulas wrote:
> >* Does anyone know why dev/kloader.c calls namei and then vn_open on
> >the same path? I remember seeing this before and leaving it alone
> >because nobody I could find was sure what the deal was, but it's
> >unlikely to work
A couple days ago it came to my attention that the hack used for
cloning devices (returning a magic error code and stuffing a file
descriptor number in a magic field of struct lwp) is also used by
/dev/stderr, and more importantly, every caller of vn_open in the
kernel (there are many) needs to
I ran into problems with pthread_cond_timedwait today, which I filed
in gnats because I don't have any more time to look at it for the
moment. The short summary is that I was getting all manner of broken
behavior (e.g. spurious wakeups that appear impossible from code
examination) and my best
On Sat, Jun 19, 2021 at 08:12:38AM +, nia wrote:
> The Zig developer found the kernel limit:
> https://nxr.netbsd.org/xref/src/sys/kern/vfs_lockf.c#116
>
> but it doesn't seem to be adjustable through sysctl.
> I wonder if it should be.
I wonder if the logic should be changed to allow
On Tue, Jun 01, 2021 at 10:08:55AM -0700, Brian Buhrow wrote:
> hello David. What I don't see in your proposal is a way of
> implementing a dynamic device filesystem.
As I already posted about once, that's irrelevant to what I'm
proposing.
A working devfs that can be used in all places
On Sat, May 29, 2021 at 04:17:13PM -0700, John Nemeth wrote:
> We should really get with the times and create a devfs. I
> know that there are people that disagree with this (likely including
> you), but the archaic device node system causes a lot of headaches
> and it's time that we
On Sun, May 30, 2021 at 12:00:16AM +0200, Johnny Billquist wrote:
> On 2021-05-29 22:26, David Holland wrote:
> > There are a number of infelicities in the way we currently handle the
> > I/O plumbing for devices in the kernel. These include:
>
> [...]
>
>
On Sat, May 29, 2021 at 05:41:38PM -0400, Mouse wrote:
> There is, however, one thing I think is missing in your rework
> proposal. I see nowhere to fit in a one-off driver for idiosyncratic
> hardware - or as a pseudo-device interface to idiosyncratic kernel
> code. I've personally done
There are a number of infelicities in the way we currently handle the
I/O plumbing for devices in the kernel. These include:
- cloning devices exist but as currently implemented violate
layering abstractions;
- every file system needs to have cutpaste vnode ops tables for
device
On Fri, Feb 19, 2021 at 08:47:16AM -0500, Greg Troxel wrote:
> I see our man page addresses this with FDISKSYNC. It sounds like you
> aren't proposing to change this (makes sense), but there's the pesky
> issue of errors within the disk when writing from cache to media.
> Perhaps those are
On Fri, Feb 19, 2021 at 08:33:03AM -0500, Greg Troxel wrote:
> Maybe I'm way off in space, but I'd like to see us be careful about
>
> 1) operating system has a succcessful return from a write transaction to
> a disk controller (perhaps via a controller that has a write-back
> cache)
On Thu, Feb 18, 2021 at 11:00:15PM -0500, Mouse wrote:
> > (3) I think the drawbacks of reporting user 1's I/O errors to user 2
> > [...] mean that we should guarantee that I/O errors from *your*
> > writes should be reported by *your* call to fsync. [...]
>
> > (3a) I don't think it's
I have been going through various code paths (hence all the posts and
commits about obscure details) with an eye toward documenting what we
do and do not guarantee about files to applications... and I've gotten
to fsync.
In an ideal world, if you write some data and later when it gets
written to
On Thu, Feb 18, 2021 at 06:56:00PM -0500, Greg Troxel wrote:
> > And report any errors to me, so if you're a database and I'm feeling
> > nasty I can maybe mess with you that way. So I'm not sure it's a great
> > idea.
> >
> > Right now fsync error reporting is a trainwreck though.
>
> I
On Tue, Feb 16, 2021 at 05:29:00PM +0700, Robert Elz wrote:
> We could, of course, invent new interfaces (a write variant with an
> extra pointer to length written arg perhaps, or where the length arg
> is a pointer to a size_t and that is read and then written with either
> the amount
On Wed, Feb 17, 2021 at 01:17:14PM -0500, Greg Troxel wrote:
> > Last year, fdatasync() was changed to allow syncing files opened
> > read-only, because that ceased to be prohibited by POSIX and something
> > apparently depended on it.
>
> I have a dim memory of this and mongodb.
>
> >
Last year, fdatasync() was changed to allow syncing files opened
read-only, because that ceased to be prohibited by POSIX and something
apparently depended on it.
However, fsync_range() was not also so changed. Should it have been?
It's now inconsistent with fsync and fdatasync and it seems like
(This came up in chat, and since there was no agreement at all there
it seems it ought to be discussed here.)
It is possible for write() calls to fail partway through, after
already having written some data. We do not currently document the
behavior under these circumstances (though we should),
On Sat, Jan 09, 2021 at 08:33:27AM -0500, Mouse wrote:
> Waking up this thread from about a month ago
>
> [...]
>
> This makes me wonder if perhaps login sessions should have their
> stdin/stdout/stderr set up on /dev/tty instead of the actual ctty
> device. But if that's done, will
On Tue, Nov 24, 2020 at 09:09:59AM +1100, matthew green wrote:
> > @@ -395,9 +401,8 @@ pipeunlock(struct pipe *pipe)
> >KASSERT(pipe->pipe_state & PIPE_LOCKFL);
> >
> >pipe->pipe_state &= ~PIPE_LOCKFL;
> > - if (pipe->pipe_state & PIPE_LWANT) {
> > - pipe->pipe_state &=
mjg at freebsd says that their pipes have a thundering herd problem
that manifests in make's token pipe stuff at high -j values. We have
the same logic, and it's easily fixed.
Completely untested patch follows; does anyone object to this assuming
that it works (possibly after minor changes)?
On Thu, Nov 12, 2020 at 12:49:13PM +, nia wrote:
> > Many years ago, I made it so that mixer operations
> > would fall though and complete successfully (can't find the commit now).
> >
> > [...]
>
> Thanks. Sounds pretty similar to some problems I observed in native
> libossaudio
On Wed, Nov 11, 2020 at 05:20:53AM -, Michael van Elst wrote:
> >But WS_KERNEL_FG=WSCOL_LIGHT_BROWN (I wanted yellow, that looks like
> >the closeset available approximation) and WS_KERNEL_BG=WSCOL_BLUE?
> >Once wscons switches, everything is as I would expect - but, before
> >that, it's
On Tue, Nov 10, 2020 at 06:39:53PM -0500, Mouse wrote:
> NetBSD/amd64, 9.1.
>
> What controls the colours used for console text output before wscons
> takes over? When I build a kernel with WS_KERNEL_FG=WSCOL_GREEN and no
> WS_KERNEL_BG, I see green on black, both before and after the
On Sat, Oct 10, 2020 at 03:54:32PM -, Christos Zoulas wrote:
> Aside for the TIOCGSID bug which I am about to fix (it is in tty_43.c
> and is used in libc tcgetsid(), all the compat tty ioctls are defined
> in /usr/src/sys/sys/ioctl_compat.h... We can empty that file and try
> to build the
On Mon, Oct 12, 2020 at 01:23:15PM +1100, matthew green wrote:
> > Switch the last user (ypserv) from CIRCLEQ to TAILQ.
> > This is inspired by analogous refactoring from OpenBSD:
> >
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
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
On Mon, Aug 24, 2020 at 12:01:27PM +0100, David Brownlee wrote:
> > > I think the general consensus is that ffs can be inconsistent it ways
> > > fsck is unable to detect.
> >
> > ...much less fix. Yes. When I was doing the program that eventually
> > got massaged into resize_ffs, during
On Sun, Aug 23, 2020 at 08:14:31PM +0100, David Brownlee wrote:
> One of the rsync processes hung, and upon reboot fsck checked the
> filesystem and marked it clean, but after a while it happened again,
> and then again a third time.
>
> This time I've run fsck -f repeatedly and each time it
On Sat, Aug 15, 2020 at 07:24:01AM -0400, Mouse wrote:
> >>> What I observe is that a process that explicitly ignores SIGCHLD
> >>> (SIG_IGN), then forks a child which exits, when wait()ing for the
> >>> child, gets ECHILD (i.e., wait returns -1 and errno is ECHILD).
> >> And the ECHILD return
On Fri, Aug 14, 2020 at 03:51:12PM -0400, Mouse wrote:
> > What I observe is that a process that explicitly ignores SIGCHLD
> > (SIG_IGN), then forks a child which exits, when wait()ing for the
> > child, gets ECHILD (i.e., wait returns -1 and errno is ECHILD).
>
> And the ECHILD return is
On Sun, Jul 26, 2020 at 11:20:37PM +, m...@netbsd.org wrote:
> > To be explicit:
> >
> > It is the same underly problem either way, and it is worse in practice
> > with WAPBL than without because WAPBL ffs runs faster than non-WAPBL
> > ffs and thus accumulates more unwritten blocks.
>
On Thu, Jul 23, 2020 at 07:45:08AM +0200, Micha? G?rny wrote:
> > > Rationale: the default filesystem (FFS) without WAPBL is more prone to
> > > data loss.
> >
> > It is not, unfortunately. We had WAPBL on by default some time back
> > and eventually switched it off.
> >
> > The problem
On Thu, Jul 23, 2020 at 05:17:33AM +, David Holland wrote:
> The problem is that because it still doesn't do anything about
> journaling or preserving file contents, but runs a lot faster, it
> loses more data when interrupted.
Note since someone already asked: that shoul
On Wed, Jul 22, 2020 at 11:24:16PM +0200, Kamil Rytarowski wrote:
> I propose to enable WAPBL ("log" in fstab(5)) by default for 10.0 and newer.
> [...]
>
> Rationale: the default filesystem (FFS) without WAPBL is more prone to
> data loss.
It is not, unfortunately. We had WAPBL on by
On Fri, Jul 10, 2020 at 08:41:40PM +0700, Robert Elz wrote:
> I have spent a little time looking at this now, and I think
> it is just all a mess.
Indeed...
> As best I can work out, and someone correct me if I'm wrong,
> the whole purpose of pg_jobc is so that orphanpg() can be called
>
On Tue, Jun 16, 2020 at 12:21:33AM +0100, Roy Marples wrote:
> On 16/06/2020 00:07, David Holland wrote:
> > Kamil thinks that. I don't see why. Compiling data into tools just
> > complicates everything.
>
> libterminfo.so has some terms compiled into it if the databa
On Mon, Jun 15, 2020 at 10:56:04PM +, David Holland wrote:
> A less glib example: line 3186 of vfs_syscalls.c, in stat or more
> precisely sys___stat50, has a handwritten call to copyout() to
> transfer the stat results back to userspace.
To amplify:
Currently syscalls.master s
On Mon, Jun 15, 2020 at 10:15:09PM +0200, Reinoud Zandijk wrote:
> It would be great if that can be done for the ioctls dispatch code
> as well and cover their copyin/copyout stuff, its now all over the
> place; I think that would save a lot of hidden bugs. Is there a
> specification that
On Mon, Jun 15, 2020 at 09:19:19AM +0200, Martin Husemann wrote:
> > It seems to me that all of the following is mechanical and should be
> > automatically generated, beyond what makesyscalls already does:
> >- all the code that calls copyin/copyout
>
> It is probably too early and I had
On Sun, Jun 14, 2020 at 02:21:07PM -0700, Paul Goyette wrote:
> > (2) What is the installed syscall description file called and where
> > does it go? It is likely to be derived from (i.e., not the same as)
> > syscalls.master. It isn't a C header file so it doesn't belong in
> > /usr/include.
On Sun, Jun 14, 2020 at 11:59:54PM +0200, Johnny Billquist wrote:
> > "usr.bin/makesyscalls" sounds good to me.
>
> Uh? usr.bin is where stuff for /usr/bin is located, right? Anything there
> should be pretty normal tools that any user might be interested in. Don't
> seem to me as
As I mentioned a few days ago the reason I was prodding
makesyscalls.sh is that I've been looking at generating more of the
system call argument handling code.
It seems to me that all of the following is mechanical and should be
automatically generated, beyond what makesyscalls already does:
-
On Fri, Jun 12, 2020 at 04:40:28PM +0200, Reinoud Zandijk wrote:
> > Yes, it can be rewritten in C as a subsequent step. *After* quite a
> > bit of tidying. And no, I'm not doing that now. Among other problems,
> > compiling it requires bikeshedding where to put it in the tree. Feel
> > free
Does anyone know what the files sys/rump/kern/lib/libsys_*/syscalls.master
are for and/or how they're used?
They don't seem to have been built with makesyscalls; there's some
suggestion that makesyscalls might be run on them on the fly during a
build (which would be wrong)... but the makefile
On Wed, Jun 10, 2020 at 01:25:03AM -0400, Thor Lancelot Simon wrote:
> Could you translate your prototype into a
> different language, one that's less basically hostile to our build system
> and its goals and benefits?
Like which one? You removed the part of the post that explained that
there
1 - 100 of 791 matches
Mail list logo
