Re: Change max ttys from 8 to 12?
On Tue 19 Dec 2023 at 12:38:19 -, Michael van Elst wrote: > Bumping both limits to 12 (and augmenting keysyms and the keymaps > for this) would align this with the other *BSDs. I agree. It removes an arbitrary asymmetry. > The con side here is that some keyboards either only have 10 function > keys or already use F11 and F12 for other purposes (like DEC keyboard > has F11=ESC, so ctrl-alt-f11 invokes DDB). Sure, but most of the keyboards have 12 function keys and even if some don't, nobody is forced to try to use them. -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: ATA TRIM?
On Thu 08 Dec 2022 at 10:23:19 -0500, Mouse wrote: > I wrote > > > I'm trying to understand TRIM, such as is used on SSDs. [...] > > I forgot to ask: does anyone know whether TRIM is known to work? It It could perhaps be that the area you're trying to trim is too small, or badly aligned? -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: [PATCH] ISO abd JIS for ADB (Was: two keys with same keycode on ADB)
On Thu 12 May 2022 at 22:54:44 -0400, Michael wrote: > Emmanuel Dreyfus wrote: > > > I am also a bit puzzled that in our historical code, ANSI ADB > > scancode 42, which is supposed to be backslash (the key is between > > backspace and return), is converted into USB scancode 50, which > > is non US hash. I did not change it, but here again, input from > > someone that has access to that keyboard would help. > > It's there because hidkbdmap.c has > KC(50), KS_backslash, KS_bar, Could that have something to do with UK layout? The key near ENTER (but not as described between enter and backspace) is #/~. See e.g. https://en.wikipedia.org/wiki/British_and_American_keyboards -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: valgrind
On Tue 22 Mar 2022 at 20:59:05 +, Koning, Paul wrote: > > But these sorts of strategies require bigger function pointers, which > > you basically can't do in C. > > Can't you? Does C require function pointers to have the same type, or > compatible structure, as data pointers? No, I don't think that it does. You could have different sizes for those. However there are, I fear, too many programs that somewhere convert a function pointer to (void *) and at that point things break. And there is not really a "generic function pointer type" that you could sensibly use instead, I think. > If it does, that would mean you can't get a pointer to a nested > function, which is no different from the C++ rule that you can't get a > (plain function) pointer to a member function. True. But the trampoline function on the stack are only needed to create a pointer to a nested function. I don't think there is any issue if you never create such pointers. But that would make nested functions a lot less useful. You couldn't use one with qsort(3) for instance (as the comparison function), which is exactly the sort of scenario that would be perfect for a nested function. Possibly, a trampoline could be created on the heap, and then made executable and un-writable. Maybe that's considered too complicated / system dependent / expensive by gcc? > paul -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: valgrind
On Tue 22 Mar 2022 at 21:53:37 +0100, Rhialto wrote: > No, a common way to do it (as in the Dragon Book), if I recall > correctly, the address of the function combined with a stack frame > pointer. And nested functions keep a static link to the lexically > enclosing scope, or alternatively a "display". https://pages.cs.wisc.edu/~fischer/cs536.s06/course.hold/html/NOTES/8.RUNTIME-VAR-ACCESS.html explains both methods briefly, for those interested. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: valgrind
On Tue 22 Mar 2022 at 17:46:49 +, Koning, Paul wrote: > I don't believe ALGOL implementations needed executable stacks to implement > nested functions, for example. No, a common way to do it (as in the Dragon Book), if I recall correctly, the address of the function combined with a stack frame pointer. And nested functions keep a static link to the lexically enclosing scope, or alternatively a "display". I'm not sure if A68 would automatically move locals from surrounding scopes into the heap (like in a closure); it could well be that there was run-time checking instead if you tried to use a function pointer outside of the scope of any of the locals it used. But these sorts of strategies require bigger function pointers, which you basically can't do in C. > paul -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: valgrind
On Sun 20 Mar 2022 at 23:17:57 -0400, Mouse wrote: > clang is - or at least was last I checked - under the impression that > nested functions are little-used and thus are not worth supporting. I guess they can think so because nested functions are a gcc extension. Quite a useful one, I think, having been taught programming with Algol 68 which of course does have nested functions; but an extension nevertheless. I found an interesting article about why they're bad... https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFH falu.nl@rhialto signature.asc Description: PGP signature
Re: wsvt25 backspace key should match terminfo definition
On Thu 25 Nov 2021 at 08:01:48 -0500, Mouse wrote: > One of my very-spare-time projects is to move input line editing out of > the kernel. Move it into a separate line-editor process and then you > can choose your input line editor just as you can, today, choose your > shell. I'm still mulling over the design issues involved, though, On the Amiga there was CONMAN: which could replace CON: as a console window, and it had nice extras like line editing. It also kept track of the user process' current directory so it could also do file name completion. On the V7 I used initially, a local patch had added more-like paging to the kernel's terminal driver. Quite useful on ADM-3a terminals without scrollback... I never got around to add this to NetBSD, unfortunately. But it's a lot less needed in an xterm. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: wsvt25 backspace key should match terminfo definition
On Thu 25 Nov 2021 at 00:16:36 +, RVP wrote: > Or, maybe have `erase=^?' and also a new `erase2=^H' like FreeBSD does? It > seemed extravagant to have 2 erase chars. when I first encountered it, but, > now I'm beginning to see why... That's an interesting idea... historically (and I mean decades) I have setteled on choosing one (^H) and forcing all systems I used over the years to use this one setting, but this might be more convenient... (And I have been thinking of switching since ^? seems more prevalent on keyboards than ^H these days. But it would mean that I have to switch everything over more or less at once.) > -RVP -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Level for Unix-domain socket options
On Thu 05 Aug 2021 at 13:22:55 +, nia wrote: > The unix(4) man page incorrectly states: > > "A UNIX-domain socket supports two socket-level options for use with > setsockopt(2) and getsockopt(2): [...]" > > In reality, the protocol level when using these socket options > must be 0, which is a magic number not really documented anywhere > except the test suite. and getsockopt(2) says DESCRIPTION getsockopt(), setsockopt() and getsockopt2() manipulate the options associated with a socket. Options may exist at multiple protocol levels; they are always present at the uppermost "socket" level. which I interpret to mean that even if you use SOL_SOCKET for these options, it should work. Do I read that as intended? I understand from the above that it is not true for these options. Perhaps it should be fixed so that the options work for both SOL_LOCAL and SOL_SOCKET level: compatible with both (at least some) practice and documentation. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: VOP_STRATEGY for devices and pipes
On Wed 14 Jul 2021 at 21:14:16 -0700, Paul Goyette 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 an extended attribute on that inode, then surely it will get stored in the file system, and not in the fifo (or device)? So if the fifo (or device) code gets involved in this, then the bug is there, I'd think? -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFH falu.nl@rhialto signature.asc Description: PGP signature
Re: Devices.
On Sun 30 May 2021 at 19:30:04 -0400, John Franklin wrote: > Consider, a USB device is inserted... > that has a mass storage block device... > encrypted with CGD... > hosting a partition map... > with an LVM PV in one of the partitions... > that contains three LVs. > > How many device nodes are created here? If I were to design a devfs for this, the resulting device nodes would become a directory tree, for the given case something like sd0-+-cgd0-+-cgd0a-+-pv0-+-lv0 |-lv1 \-lv2 "Somehow" these nodes would be device nodes and directories at the same time. That would be much nicer than having two nodes (with slightly different names), one for the device node and one for the directory. I don't think I've seen a devfs like that; there is a hierarchy in the linux /sys/devices but it is determined by physical hardware attachment. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: 9.1: boot-time delay?
On Tue 18 May 2021 at 15:40:05 -0400, Mouse wrote: > This leads me to the depressing conclusion that it is probably one of > the video drivers, which are not optional for the operational kernel. I was going to suggest that even before reading this mail. I noticed in my new machine that with an nVidia card there was a pause similar to what you described. It went away when I put in a Radeon card instead. The nVidia was also not-quite-functional, so I wanted to get rid of it anyway. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Inconsistencies in usage of "locators" argument to config (*ca_rescan)() functions
On Sat 27 Mar 2021 at 02:12:36 +0300, Valery Ushakov wrote: > On Fri, Mar 26, 2021 at 13:18:16 -0700, Jason Thorpe wrote: > > > I think it may have been the terminology used by Chris Torek in his > > paper on the new 4.4BSD device auto configuration framework [...]. > > Sadly, that paper is somewhat hard to find, and I don't know if it > > was ever actually published anywhere. > > This one? :) > > http://www.netbsd.org/docs/kernel/config-torek.ps Seems so! The file is a bit annoying postscript (backwards, and pages cannot be viewed independent from others). Here are some quotes: p.2: In many cases, each bus driver can probe the bus all by itself. This is called /direct configuration/, and is preferred because it finds physically-connected hardware regardless of the presence of proper drivers and configurations. Sometimes, however, the driver needs "hints" as to what to try. This sort of /indirect configuration/ is more general and is also provided. p.14: [A]utoconfiguration can be run "forwards" (directly) or "sideways" (indirectly). Direct configuration is better, because it detects hardware that is physically present even if is not configured into the system, but it can be used only on "self-describing" buses. The SnailBus, for instance, [ explains the SnailBus, which seems similar to PCI, and then p.15ff explains the configuration process more deeply ] > -uwe -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Inconsistencies in usage of "locators" argument to config (*ca_rescan)() functions
On Wed 24 Mar 2021 at 13:37:53 -0700, Jason Thorpe wrote: [ explanation of direct and indirect configuration ] Is there any reason why it's called direct and indirect? I can't really match those names to the procedures. Maybe some other names would be better, perhaps "config driven" and "hardware driven", or "fixed" vs "autodetect" or something like that? -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: partial failures in write(2) (and read(2))
On Thu 11 Feb 2021 at 09:41:50 -0500, John Franklin wrote: > From the application?s perspective of calling write() in libc, when > there is such an error the libc function could return a short response > and set errno. That doesn?t work so much for the kernel?s system > call. A system call with error can return with the carry set and the error and short count returned in a separate registers. The carry bit is how errors used to be indicated since at least V7 (even V6?) anyway. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Reparenting processes?
On Sun 10 Jan 2021 at 16:57:43 -0500, Mouse wrote: > That made no sense to me either. Neither does the test that forbids > process group leaders from setsid()ing. That can at least partially be explained, at least if one rephrases it first as "session leaders are forbidden to setsid()". A process is a session leader if its session id is equal to its process id. This is similar for process groups. Now setsid() creates a new session AND a new process group, and the current process is to be the leader of both. A process that is already a session|group leader of any session|group cannot therefore become the leader of a new session|group. This reasoning works for the POSIX session, which has session ids. The old BSD did not have session ids so part of the reasoning doesn't work directly. But there may be still a prohibition there if a session leader is by necessity also always a process group leader. This indeed seems to be the case, since setsid() makes it so, and a group leader cannot give up its leadership. Now if the setsid() limitation was designed first, and then the ids were designed this way... or the ids were first, and the setsid() limitation was deemed acceptable... that we will have to guess. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Reparenting processes?
rv = 0; } else rv = EINVAL; mutex_exit(_lock); return (rv); } return (VOP_IOCTL(ttyvp, cmd, addr, flag, NOCRED)); } It seems that the ctty vnode pointer from the session, once set, is never allowed to go back to NULL (unless by creating a new session with a fresh NULL pointer in it). This despite that /dev/tty could handle that. [Stevens] "Advanced Programming in the UNIX Environment" from Stevens is more explanatory about sessions etc (but it also says that BSD has no session IDs, but by now NetBSD clearly does have them). ([Stevens] writes on p.246 "The session leader that establishes the connection to the controlling terminal is called the controlling process" and "... the hang-up signal is sent to the controlling process (the session leader)"). In other words, controlling ttys are pretty strongly associated with the session leader process, which seems to match the code. Unfortunately [Stevens] also doesn't cover the corner case either. > /~\ The ASCII Mouse -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Reparenting processes?
On Sun 10 Jan 2021 at 09:44:18 -0500, Mouse wrote: > >> 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 the `real' ctty device even be > >> open? [...] > > It actually occurs to me that this is a potential problem even today: > what happens if all the processes in a session close the descriptors > they have on the ctty, and there are no others lying around in other or similarly, if they TIOCNOTTY it (although tty(4) tells me it's obsolete) > processes, and then one of those processes tries to access /dev/tty? > It would be an unusual session, true, but there's nothing preventing it > from happening as far as I can see. Would the underlying tty driver > explode upon getting I/O calls when it isn't open, or what? I think sys/kern/tty_tty.c is the implementation of /dev/tty, and it seems you get ENXIO. Also each read/write call goes to the *current* controlling tty, freshly looked up. > /~\ The ASCII Mouse -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Sample boot.cfg for upgraded systems (rndseed & friends)
On Tue 22 Sep 2020 at 19:59:22 +0100, David Brownlee wrote: > What would people think of installing an original copy of the etc set > in /usr/share/examples/etc or similar - its 4.9M extracted and ~500K > compressed and the ability to compare what is on the system to what it > was shipped with would have saved me so much effort over the years :) I think it already ends up in /.sysinst/etc ? -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: wait(2) and SIGCHLD
On Sat 15 Aug 2020 at 19:57:26 -0400, Terry Moore wrote: > David Holland 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? My first thought was that daemon(3) does something like that already (the idea sounds familiar to me), but it does just a single fork(2) and a setsid(2). -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: SIGCHLD and sigaction()
On Sat 15 Aug 2020 at 16:46:13 -0400, Mouse wrote: > Personally, I don't like it; I think signals should be much like > hardware interrupts in that a second instance happening before the > first is serviced gets silently merged. If you want some sort of > queued notification of child death, it seems to me a much righter, much > more UNIXy, tack to take is to add something like AF_CHILD sockets or > some such and get child death notifications that way. (Actually, I'm > not sure sockets would work without severe hackery; too much of the > socket machinery assumes the data in a socket is independent of who > reads from it. Perhaps it would need a new flavour of file descriptor, > akin to kevent or timerfd descriptors. Linux has apparently done this: pidfd (file descriptors representing a process). The idea is that you can pass them to various system call variants that otherwise take pids, without the risk that the process has exited in the mean time and the pid re-used. See https://man7.org/linux/man-pages/man2/pidfd_open.2.html Personally I'd think you should be able to get pidfds from the /proc file system, but here Linux seems to have missed a chance. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: style change: explicitly permit braces for single statements
On Thu 16 Jul 2020 at 13:08:49 -0400, Ted Lemon wrote: > It sounds like we need a better tool. FWIW, when actually working on > code, I've found that 120 is a better width than 80 -- with 80, there are > just too many line breaks. But I don't mean to say that your > preference is wrong -- what sucks is that we have to compromise, instead > of having tools that present the text the way that we want to consume > it without changing anything in the underlying file. E.g. web browsers > just reflow the text when you change the window width. Why don't we > have this for code editors? I have seen an editor (I think it was google's Android development environment) that even went so far as to recognize some particular boilerplate Java code fragments, and abbreviated them. You could unfold them if you wanted though. I wasn't sure if I liked that or hated it. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: style change: explicitly permit braces for single statements
On Mon 13 Jul 2020 at 09:48:07 -0400, Mouse wrote: > I'd actually recommend one exception, that being the else-if chain: if > the dependent clause after an else is a single statement, and it is an > if statement, then, depending on the semantic relationship of the inner > if's test to the enclosing if's, I can go either way on whether I'd > prefer braces or no braces around the inner if. I agree with the proposal at the start of the thread and I also agree with this. I guess that some languages have a special 'elif' or 'elseif' keyword just because of this. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: pg_jobc going negative?
On Fri 10 Jul 2020 at 20:41:40 +0700, Robert Elz wrote: > 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 > when a process group is orphaned (no longer has a session leader). > > If it has any other use, I cannot see it. It also seems to be involved in deciding wether to send a SIGTTOU or SIGTTIN to a process (i.e., to suspend a process if it tries to read from the tty, but it is in the background). In sys/kern/tty.c and sys/kern/tty_pty.c. > Or, we could properly define what pg_jobc is counting, and then make sure > that it counts whatever that is properly - is incremented in all the > appropriate places, and decremented properly as well. Currently > the comment about it in proc.h is: > /* > * Number of processes qualifying >* pgrp for job control > */ > which makes it clear that it is a reference counter (not necessarily > counting the number of something which exists, so that something can be > deleted, but it is counting references to processes). Unfortunately > I have no idea what "qualifying pgrp for job control" is supposed to mean. I found this above fixjobc() which goes into a bit more detail what is being counted: /* * Adjust pgrp jobc counters when specified process changes process group. * We count the number of processes in each process group that "qualify" * the group for terminal job control (those with a parent in a different * process group of the same session). If that count reaches zero, the * process group becomes orphaned. Check both the specified process' * process group and that of its children. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Adding an ioctl to check for disklabel existence
On Thu 03 Oct 2019 at 10:17:47 -0700, John Nemeth wrote: > On Oct 3, 2:42pm, Rhialto wrote: > } I was thinking the other day that it might be useful if gpt had a > } subcommand to spit out a script to duplicate the partitioning of a disk, > } but without the "unique" parts. The script would of course be > } hand-editable for any changes one might want to make. > > By "unique" parts, do you mean just the UUIDs, or do you mean > other parts as well? What would the output look like? Just the UUIDs, those are the things I'm aware of. The sort of script I was thinking of would be something like this: gpt destroy sd1 gpt create sd1 gpt add -a 2m -l efi -s 128m -t efi sd1 gpt add -a 2m -l root -s 768m -t ffs sd1 gpt add -a 2m -l var -s3g -t ffs sd1 gpt add -a 2m -l swap -s 8200m -t swap sd1 gpt add -a 2m -l usr -s 20g -t ffs sd1 gpt add -a 2m -l tmp -s 1024m -t ffs sd1 gpt add -a 2m -l home -s 128g -t ffs sd1 It would leave out all/most things that are defaulted. (probably when automatically generated it would use the -a alignment only on the first partition, or if there is unused space between them) (maybe it would even use some shell variables for things like the disk device) > The bit about not modifying it is more of a caution. You can > modify it if you're careful (checksums are recomputed during > restore). Obviously if you make an error, it may not be usable > for restore, so you should work with a copy. Yes, when I wanted to clone the partitioning of my disk, I was indeed thinking of modifying the output from 'gpt backup', but it seemed a bit easier to create a little script such as the above, in case I want to make the same partitions again later. (In fact the version that I really used had some "are you sure" type prompts in it) -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Adding an ioctl to check for disklabel existence
On Wed 02 Oct 2019 at 19:40:01 -0700, John Nemeth wrote: > Cloning disks always presents issues. However, gpt(8) has > grown a "uuid" command to generate new UUIDs. This was primarily > done to help with the cloning problem. Cloning a disk and then > putting two disks with the same UUIDs on the same system is an > operator error. I was thinking the other day that it might be useful if gpt had a subcommand to spit out a script to duplicate the partitioning of a disk, but without the "unique" parts. The script would of course be hand-editable for any changes one might want to make. Such functionality would be the equivalent of using disklabel to get the editable text-version of a disklabel from one disk, and applying it to a different disk. I use this sort of thing if I want to create a backup disk which should have the same layout as the original. There is "gpt backup", but the manual page mentions "It should not be modified" and it contains the guids of the partition which in many cases should NOT be duplicated. It also isn't very readable. The intermediate solution I have used so far is to partition my disks in all cases using a simple script, and keep the script corresponding to each disk, so that I can use it again later. But if you didn't originally partition a disk this way, it doesn't help. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: panic: UBSan: Undefined Behavior in /syzkaller/managers/netbsd-kubsan/kernel/sys/kern/kern_rndq.c:LINE, negation of -ADD Reply-To:
On Sat 28 Sep 2019 at 09:01:28 +0200, Martin Husemann wrote: > There is also the question whether it would be best to just disable > ubsan here and restore the original solution. Maybe you're talking about some other detected UB here? The code in kern_rndq.c that I'm touching in my patch has been there (according to cvs annotate) since 2014 with some small changes in 2015. > Martin -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: panic: UBSan: Undefined Behavior in /syzkaller/managers/netbsd-kubsan/kernel/sys/kern/kern_rndq.c:LINE, negation of -ADD Reply-To:
n anymore:
// if (delta2 < 0)
// delta2 = -delta2; /* back to ~32 bits */
if (delta2 > d->dx)
delta3 = delta2 - d->d2x; // u32 - u32 makes u32
else
delta3 = d->d2x - delta2; // u32 - u32 makes u32
// can't happen anymore:
// if (delta3 < 0)
// delta3 = -delta3;
d->x = v;
d->dx = delta;
d->d2x = delta2;
/*
* If any delta is 0, we got no entropy. If all are non-zero, we
* might have something.
*/
if (delta == 0 || delta2 == 0 || delta3 == 0)
return 0;
d->outbits++;
return 1;
}
/*
* Delta estimator for 32-bit timestamps.
* Timestaps generally increase, but may wrap around to 0.
* If t decreases, it is assumed that wrap-around occurred (once).
*/
static inline uint32_t
rnd_dt_estimate(krndsource_t *rs, uint32_t t)
{
uint32_t delta;
uint32_t ret;
rnd_delta_t *d = >time_delta;
if (t < (uint32_t)d->x) {
// t wrapped around
delta = UINT32_MAX - (uint32_t)d->x + t;
} else {
// t >= d->x, the normal case of slightly increasing time
delta = t - (uint32_t)d->x;
}
// can't happen any more:
// //if (delta < 0) {
// delta = -delta;
// }
ret = rnd_delta_estimate(d, t, delta);
KASSERT(d->x == t);
KASSERT(d->dx == delta);
#ifdef RND_VERBOSE
if (deltacnt++ % 1151 == 0) {
rnd_printf_verbose("rnd_dt_estimate: %s x = %lld, dx = %lld, "
"d2x = %lld\n", rs->name,
(int)d->x, (int)d->dx, (int)d->d2x);
}
#endif
return ret;
}
/*
* Delta estimator for arbitrary unsigned 32 bit values.
*/
static inline uint32_t
rnd_dv_estimate(krndsource_t *rs, uint32_t v)
{
uint32_t delta;
uint32_t ret;
rnd_delta_t *d = >value_delta;
if (v >= (uint32_t)d->x) {
// u32 - u32 makes u32
delta = v - (uint32_t)d->x;
} else {
delta = (uint32_t)d->x - v;
}
// can't happen anymore
// if (delta < 0) {
// delta = -delta;
// }
ret = rnd_delta_estimate(d, v, delta);
KASSERT(d->x == v);
KASSERT(d->dx == delta);
#ifdef RND_VERBOSE
if (deltacnt++ % 1151 == 0) {
rnd_printf_verbose("rnd_dv_estimate: %s x = %lld, dx = %lld, "
" d2x = %lld\n", rs->name,
(long long int)d->x,
(long long int)d->dx,
(long long int)d->d2x);
}
#endif
return ret;
}
-Olaf.
--
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___ Anyone who is capable of getting themselves made President should on
\X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
signature.asc
Description: PGP signature
Re: panic: UBSan: Undefined Behavior in /syzkaller/managers/netbsd-kubsan/kernel/sys/kern/kern_rndq.c:LINE, negation of -ADD Reply-To:
On Fri 27 Sep 2019 at 15:53:47 +0200, Kamil Rytarowski wrote: > On 27.09.2019 10:19, Rhialto wrote: > > On Thu 26 Sep 2019 at 01:15:23 +0200, Kamil Rytarowski wrote: > >> Is this patch correct? > >> > >> http://netbsd.org/~kamil/patch-00168-kern_rndq.c-avoid-overflow.txt > >> > >> This code will map the corner case into defined semantics, treating > >> delta INT32_MIN as INT32_MIN+1. > > > > I don't know if it is important, but it makes the "normalized" delta > > value INT32_MAX more likely than it probably should be, since it can > > result from "raw" delta values INT32_MIN, INT32_MIN+1, and INT32_MAX. > > > > Similarly, 0 is underrepresented as output, since it only can result > > from 0. > > > > Other positive results x can come from x and -x as inputs. > > > > -Olaf. > > > > If you think that it shall be represented a 0, I can go for it. > I have been pondering it for a while and it seems more complicated than I first thought... it seems that the actual value of delta isn't even important, but what rnd_delta_estimate() makes of it. That calculates a derivative and a second derivative. So then one would think that creating discontinities in the time sequence of delta values, since that would likely lead to mis-estimations. (Or at least big changes compared to what it calculates now) But if the actual magnitude of delta isn't even important (due to the differentials), then one could get rid of all the negative delta values by simply always using delta-INT32_MIN (a.k.a. delta+INT32_MAX+1). That maps the range [ INT32_MIN, INT32_MAX ] to [0, UINT32_MAX ]. To bad that rnd_delta_estimate() doesn't accept unsigned integers but only signed ones. (Why? A delta between two n-bit integerrs needs n+1 bits, so one would expect it to take int64s...) To correct for that, maybe (delta-INT_MIN)/2 would be a solution (if calculated without causing overflows). The different calculations throw away information in different ways: the current code that essentially takes abs(delta) sees a no entropy in the delta sequence 1,-1,1,-1, But the (delta-INT_MIN)/2 method sees nothing in 1,2,1,2,... So my final thought is that it is perhaps best to adjust rnd_delta_estimate() to take delta in an int64_t or uint32_t. After all, rnd_delta_t already contains uint64_ts for the first and second order differentials. With 32-bit samples and 33-bit deltas, 64-bits are certainly enough there. Then (delta-INT_MIN) can simply be used. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: panic: UBSan: Undefined Behavior in /syzkaller/managers/netbsd-kubsan/kernel/sys/kern/kern_rndq.c:LINE, negation of -ADD
On Thu 26 Sep 2019 at 01:15:23 +0200, Kamil Rytarowski wrote: > Is this patch correct? > > http://netbsd.org/~kamil/patch-00168-kern_rndq.c-avoid-overflow.txt > > This code will map the corner case into defined semantics, treating > delta INT32_MIN as INT32_MIN+1. I don't know if it is important, but it makes the "normalized" delta value INT32_MAX more likely than it probably should be, since it can result from "raw" delta values INT32_MIN, INT32_MIN+1, and INT32_MAX. Similarly, 0 is underrepresented as output, since it only can result from 0. Other positive results x can come from x and -x as inputs. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: NCHNAMLEN vnode cache limitation removal
On Fri 13 Sep 2019 at 18:04:06 +, David Holland wrote: > On Wed, Sep 11, 2019 at 09:43:18AM +0300, Jason Thorpe wrote: > > Another advantage of de-duping the name strings is that you can > > compare names by testing pointer equivalence. > > I'd expect that trying to dedup the strings would destroy all the > available parallelism. One could have a hybrid method: if the pointers are the same, the strings surely are, and otherwise the strings can be compared as before. Maybe a string that is detected as duplicate in the second case can be easily reduced to the deduped version from that point onwards. It would need to be tested how much that wins and loses in regards to comparison time vs. parallelism and that sort of things. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: RFC: New userspace fetch/store API
On Mon 25 Feb 2019 at 18:10:20 +, Eduardo Horvath wrote: > I'd do something like: > > uint64_t ufetch_64(const uint64_t *uaddr, int *errp); > > where *errp needs to be initialized to zero and is set on fault so you can > do: > > int err = 0; > long hisflags = ufetch_64(flag1p, ) | ufetch_64(flag2p, ); > > if (err) return EFAULT; > > do_something(hisflags); I like this, because it swaps the cost of the value that is always needed (which was expensive) versus the one that isn't expected often (the error case, was cheap). With this change, the return value can be stored in a register. If you take the address of the variable where you want the value to be, it can't be a register. But the error case hopefully doesn't occur often, so the error code likely doesn't even have to be stored into. > Eduardo -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: nvmm
On Mon 08 Oct 2018 at 12:02:14 +0200, Maxime Villard wrote: > Here is support for hardware-accelerated virtualization on x86 [1]. A generic Since I'm currently working at an ISP which also provides an OpenStack cloud: when can I use this with Qemu? :-) I should really go and see what the state of cloud-init is wrt NetBSD so that I can run NetBSD images in OpenStack clouds :) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: Too many PMC implementations
On Thu 23 Aug 2018 at 18:48:32 +0200, Kamil Rytarowski wrote: > Probably DTrace is not the final word in BSD and not something I intend > to defend - but it's a good solution for now - (FreeBSD already > ports/develops a potential replacement eBPF). I have played a bit with EBPF on Linux, and it feels weird to use a "packet filter" bytecode-based thing for performance monitoring. Don't we already have a bytecode interpreter in the kernel in the form of Lua? I hardly know anything of Lua, but using that (being an existing tool) would make somewhat more sense than a glorified packet filter (which needs a big tool set in the form of clang to compile C to EBPF bytecode). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Proposed change to makesyscalls.sh
On Mon 06 Aug 2018 at 05:07:03 +0800, Paul Goyette wrote: > Well, as I indicated before, it's not really essential to restore the > original value. If we blindly reset to sys_nomodule the only down-side > is the attempt to find an auto-loadable module on subsequent calls for > the "wrongly-tagged" syscall. sys_nomodule() could maybe even put back sys_nosys in the table in that case, for later callers. If it is certain it can't be a module. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: 8.0 performance issue when running build.sh?
tcp_delack+5b 0.00 9 0.01 kernel_lockwqinput_work+7b 0.00 3 0.00 kernel_lockroute_intr+2c 0.00 3 0.00 kernel_locktcp_ctloutput_wrapper+1f 0.00 3 0.00 kernel_lockarpintr+21 0.00 1 0.00 kernel_lockuiomove+de 0.00 1 0.00 kernel_locksyn_cache_timer+20 0.00 1 0.00 kernel_lockudp6_sockaddr_wrapper+17 0.00 1 0.00 kernel_lockudp_bind_wrapper+1e 0.00 1 0.00 kernel_lockVOP_ABORTOP+94 0.00 1 0.00 kernel_lockroute_send_wrapper+2b 0.00 1 0.00 kernel_locktcp_sockaddr_wrapper+1b 0.00 1 0.00 kernel_lockudp_disconnect_wrapper+1a -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: i2c and indirect vs. direct config
On Sun 03 Jun 2018 at 05:07:34 +0800, Paul Goyette wrote: > Please note that the X99 chip-set actually has two different SMBus > controllers! > > There's the "minimal-functionality" controller that sits on the "system > management PCI bus" and driven by the imc/imcsmb driver. But there is also > a "full-function" SMbus at "pci0 dev 31 function 3" which uses the ichsmb > driver. It is the former device via which my spdmem and sdtemp devices are > accessed. But do those two controllers access two different buses, or do they access the same bus? If the latter, the better controller can be used... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: firefox sandboxing
On Mon 14 May 2018 at 15:38:09 +0200, Thomas Klausner wrote: > We already support chroot(2). Are user namespaces > (http://man7.org/linux/man-pages/man7/user_namespaces.7.html - looks > like capabilities) something that would be good to have for NetBSD? It might help to get a NetBSD version of Docker. Although, as far as I understand Docker, you could probably get a lot of the process isolation that it needs done by writing an appropriate kauth policy? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Attempt to fix nfs client
On Sat 20 Jan 2018 at 15:45:10 +0100, Tobias Ulmer wrote: > TLDR: nfs_reqq crrptin, see diff below. Sounds like it might fix/improve http://gnats.netbsd.org/50432 ? That's also (likely) about nfs_reqq. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: CPUs and processes not evenly assigned?!
On Sun 27 Nov 2016 at 08:01:07 +, Michael van Elst wrote: > I've made a new patch: > > http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/kern_runq.diff > > -> it uses 8 guard bits (multiply by 256 instead of 2). > -> it lets you configure the moving average factor in percent >(default is 50% like now) with a sysctl. It could be slightly more efficient (no div instructions to divide by 100, but shifts to divide by 256) when the second one isn't expressed in the range [0, 100) but [0, 255). Also it feels like there is a mismatch of precision of the divided-by-100 result when using 8 bits for the fraction (only 100 out of the 256 possible fractions are used). Small thing, but easy to do. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: small changes in aesxcbcmac.c
On Sun 25 Sep 2016 at 22:01:16 +0100, Alexander Nasonov wrote:
> - while (addr + AES_BLOCKSIZE < ep) {
> + while (ep - addr > AES_BLOCKSIZE) {
I think that if ep points beyond tbe buffer (apart from the
just-past-the-end location), the subtraction is just as undefined
behaviour as before...
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
dhcpcd and routing of ipv6 prefixes
Can it be that if I use dhcpcd to obtain an IPv6 prefix from my router (a FritzBox in my case), and it assigns the prefix::1 address to the desired interface, that still no routing in that direction occurs? Here is my case: dhcpcd.conf: interface re0 noipv4 interface re1 # enable routing solicitation get the default IPv6 route ipv6rs # also the default IPv4 route will go here gateway # request an IPv6 address ia_na 1 # get a /64 and assign it to re0 ia_pd 2 re0/0 ifconfig re0: re0: ... inet 10.0.0.16 netmask 0xff00 broadcast 10.0.0.255 inet6 fe80::d63d:7eff:fe2d:6798%re0 prefixlen 64 scopeid 0x1 inet6 2001:984:4b2a:fc::1 prefixlen 64 # The route to internal addresses goes to the default (i.e. wrong) interface, # not to re0 as it should: $ route get -inet6 2001:984:4b2a:fc:226:9eff:fece:8c54 route to: vargaz.falu.nl destination: :: mask: default gateway: fe80::ca0e:14ff:feee:a54b%re1 local addr: fe80::5008:f7e9:73dd:7e21%re1 interface: re1 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1492 0 $ netstat -rn -f inet6 | grep re0 fe80::%re0/64 link#1 UC - - - re0 fe80::222:15ff:fe60:7f54 00:22:15:60:7f:54 UHLc- - - re0 fe80::226:9eff:fece:8c54 00:26:9e:ce:8c:54 UHLc- - - re0 ff01:1::/32link#1 UC - - - re0 ff02::%re0/32 link#1 UC - - - re0 $ ndp -a | grep re0 Neighbor Linklayer Address Netif ExpireS Flags murthe.falu.nl d4:3d:7e:2d:67:98re0 permanent R fe80::222:15ff:fe60:7f54%re0 00:22:15:60:7f:54re0 23h33m53s S fe80::226:9eff:fece:8c54%re0 00:26:9e:ce:8c:54re0 23h48m9s S fe80::d63d:7eff:fe2d:6798%re0d4:3d:7e:2d:67:98re0 permanent R -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Simplify bridge(4)
On Fri 12 Feb 2016 at 10:17:31 -0800, John Nemeth wrote: > tap(4) is a direct interface between userland and the network. > vether(4) would not be (although you could use BPF, etc.). It > would be an ethernet device that represents the host. If you know > how to configure Cisco devices, think BVI. As someone who tinkers with virtual machine emulators (PDP-10, PDP-11 etc) I like tap(4) very much, because it really makes it easy to make the VM communicate over ethernet with the outside world. Some other OSes also have a tap device. It would be REALLY inconvenient if suddenly NetBSD would change methods, and need not only NetBSD-dependent code but also NetBSD-version-dependent code. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Simplify bridge(4)
On Fri 12 Feb 2016 at 17:19:59 -0500, Mouse wrote: > Indeed, > I would say that bridge should not, conceptually, be a network > interface at all; I suspect it was done as a network interface simply > because that got a lot of infrastructure for free - and, if it works to > put an address on the bridge interface itself, because that part of it > _should_ be a network interface. Linux takes it even further. If you add an interface to a bridge, the interface can't be an IP endpoint any more. You have to use the bridge for that instead. That is extremely inconvenient for running VMs. The usual trick for VMs is to create a tap for it and bridge it to some real interface, for as long as the VM exists, and remove them both. But on Linux, your whole IP traffic now stops and you have to overhaul all your configuration. Which is something you don't want to do so often, so you have to basically make it the permanent configurtation, for the eventuality of wanting to run a VM. Please don't do it that way on NetBSD. It is stupid[1]. [1] I have a laptop set up that way, and some of the important userland tools get confused by it. That makes it even worse. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: How to identify specific wait-state for a "DE" process?
On Wed 06 Jan 2016 at 17:44:45 +, Taylor R Campbell wrote: > This only fixes the problem for certain orderings of file descriptors. I was thinking of a different hack. Given tha filemon now knows there are issues if it has to use a fd lower than its own fd, it can avoid the situation. If it happens, it might dup2() the output fd so that it gets one that is high enough, to use instead. That ought to work, since as I understand the issue is references to the file descriptor, not references to the file structure. Of course I can immediately see some disadvantages to this apprroach: - this will use an extra fd and that is observable by the process - and the process might even close that fd if it is doing some blanket close-all-fds action. Maybe these potential issues can be avoided somehow? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Modular raidframe
On Sun 20 Dec 2015 at 16:19:34 +0800, Paul Goyette wrote: > I like to think that I run a kernel from a third class: > > HIGHLY-MODULAR > > These kernels include only a minimum amount of built-in code, > and any additional functionality is loaded as needed. I have > fewer than 20 built-in modules, and generally run with only > 40 modules total (the difference being loaded dynamically). How does one most easily create a kernel of this type (and know which parts are loadable and which are not)? I've been making my own kernels by starting with GENERIC and removing things from it that I don't have or need. Is there a simple way to see which of those things are also modules (so they can come back if I need them after all)? The names in /stand/modules don't always seem to match 100% with words from the config file. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Freeze with BPF BIOCSFEEDBACK
On Wed 16 Dec 2015 at 23:15:11 +, Christos Zoulas wrote: > Update to bpf.c to head, I just committed a fix. Thanks! That fixes this problem. Interestingly enough, I still can't seem to communicate (I tried with telnet) between the host system and the emulated system. As before, it works between the emulated system and any other one on the network. (The original problem is that packets sent out via bpf are seen on the wire, i.e. the external network, but not by the host. The data does flow in the other direction though. I can see on the console of simh that it (tries to) send(s) ARP replies for its IPv4 address.) I thought this ioctl was supposed to fix this limitation, but it seems something still doesn't work for me. > christos -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: Freeze with BPF BIOCSFEEDBACK
On Thu 17 Dec 2015 at 17:38:33 -0500, Christos Zoulas wrote: > > I think that we need to add extra code to be able to communicate with > localhost, since that's special... But it is not a significant limitation... I thought I'd found a workaround: use bpf on a tap device which is bridged to a real device. However that doesn't seem to help, and also it breaks external communication too. But it (klh10, I said simh incorrectly before) still replies to ARP requests, so it does still get to see those. Although it seems that this scenario causes confusion over which ethernet address to use, and responds. (Changing the tap's ethernet address to be the same as the physical interface causes no error message from ifconfig tap0 link , but doesn't work either) Normally one would of course use a tap device in the normal fashion (which works for 2-way communication), but I'm reorganising things and needed to try this out. The deeper story behind it that I want to use libpcap for packet capture, so that I can remove crufty code for DLPI, PFLT, NIT (and BPF). > christos -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Freeze with BPF BIOCSFEEDBACK
I just had a freeze which likely was caused by BPF. This was with a distributed GERNERIC version of 7.0/amd64. I was running a PDP-10 emulator, klh10, https://github.com/Rhialto/klh10 which I configured to use BPF to communicate with the outside world. I ran my tops-20 installation, and as soon as the network got active, my real machine froze. Since I was in X, I could see nothing change any more. I tried it on my laptop also with 7.0 installed. Not even the caps-lock led was active. After a while it unfroze for a bit, then refroze. There were no green kernel messages. I am working on it so the actual code I ran was not exactly like in the repository. The important difference seems to be this below: #if defined(BIOCSFEEDBACK) i = 1; if (ioctl(fd, BIOCSFEEDBACK, (char *) ) < 0) esfatal(1, "BIOCSFEEDBACK failed"); #endif where fd is a BPF descriptor. which I had added. When I commented it out, and tried again, tops-20 worked fine. However, you can't communicate with it from the host. The BIOCSFEEDBACK was supposed to make that work. Any ideas? Seems like a bug... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: In-kernel units for block numbers, etc ...
On Fri 27 Nov 2015 at 08:48:07 +0700, Robert Elz wrote: > To fix this the CGD would need to fully emulate a 512 byte drive, regardless > of sector size, actually doing RMW cycles to allow updating 512 bytes in the > middle of a 4K sector (or whatever size it happens to be.) Would it make sense to create a separate layered device that converts the block size of its underlying device? At least that would separate the problem and make it simpler. And it might be useful in its own right, for instance when you dd a file system image to a drive with different blocksize. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: NFS related panics and hangs
On Thu 05 Nov 2015 at 22:30:51 +0100, J. Hannken-Illjes wrote: > This file (fs/nfs/client/nfs_clvnops.c) is part of a second (dead) nfs > implementation from FreeBSD. It is not part of any kernel. > > Our nfs lives in sys/nfs. Ok, why is it included in syssrc.tgz then? I'd say it should not be there. My other observations still stand, it seems, since they concern files in sys/nfs. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: NFS related panics and hangs
[ Adding tech-kern. The relevant earlier mails start at
http://mail-index.netbsd.org/current-users/2015/10/19/msg028233.html
This is about a default-installed amd64 GENERIC 7.0 kernel.
Replies are better in tech-kern, I think, so I set Reply-To
accordingly. ]
On Fri 23 Oct 2015 at 00:46:57 +0200, Rhialto wrote:
> This problem is very repeatable, usually within a few hours, just now it
> happened within half an hour.
>
> It seems to me that somehow the nfs_reqq list gets corrupted. Then
> either there is a crash when traversing it in nfs_timer() (occurring in
> nfs_sigintr() due to being called with a bogus pointer), or there is a
> hang when one of the NFS requests gets lost and never retried.
Looking into this:
the occurrences of nfs_reqq are as follows:
fs/nfs/client/nfs_clvnops.c: * nfs_reqq_mtx : Global lock, protects the
nfs_reqq list.
Since there is no other mention of nfs_reqq_mtx in the whole syssrc
tarball, this looks wrong. It also immediately causes the suspicion
that the list isn't in fact protected at all.
nfs/nfs.h:extern TAILQ_HEAD(nfsreqhead, nfsreq) nfs_reqq;
nfs/nfs_clntsocket.c: TAILQ_FOREACH(rep, _reqq, r_chain) {
nfs/nfs_clntsocket.c: TAILQ_INSERT_TAIL(_reqq, rep, r_chain);
nfs/nfs_clntsocket.c: TAILQ_REMOVE(_reqq, rep, r_chain);
Protected with
s = splsoftnet();
for match #2 and #3 but #1 seems not protected by anything I can see
nearby. Maybe it is
error = nfs_rcvlock(nmp, myrep);
if that makes any sense.
That function definitely does not use either splsoftnet() OR
mutex_enter(softnet_lock).
nfs/nfs_socket.c:struct nfsreqhead nfs_reqq;
nfs/nfs_socket.c: TAILQ_FOREACH(rp, _reqq, r_chain) {
nfs/nfs_socket.c: TAILQ_FOREACH(rep, _reqq, r_chain) {
match #3 is protected with
mutex_enter(softnet_lock); /* XXX PR 40491 */
but none of the others (visibly nearby).
#2 is called from nfs_receive() which uses nfs_sndlock() which also
doesn't use either splsoftnet() OR mutex_enter(softnet_lock).
nfs/nfs_subs.c: TAILQ_INIT(_reqq);
presumably doesn't need any extra protection.
softnet_lock is allocated as
./kern/uipc_socket.c:kmutex_t *softnet_lock;
./kern/uipc_socket.c: softnet_lock = mutex_obj_alloc(MUTEX_DEFAULT, IPL_NONE);
IPL_NONE seems inconsistent with splsoftnet().
I never studied the inner details of kernel locking, but the diversity
of protections of this list doesn't inspire trust at first sight...
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
signature.asc
Description: PGP signature
Re: mount_checkdirs
On Mon 06 Jul 2015 at 09:58:59 +, David Holland wrote: Also it's occasionally useful to mount over things and leave a process underneath, which this logic seems to complicate. If I read the code correctly, it looks for processes that have a current working directory or root directory exactly at the mount point. But the mount point directory does not need to be empty. A process could have a cwd or root in any directory inside it. So as-is, the code is insufficient for its intended purpose anyway. Furthermore, the process can have open files from that directory tree. If its cwd or root gets changed (and into what exactly, if it isn't the exact mount point?) it has files open that it can't find anymore with another call to open(2). That seems like an inconsistency that we may want to avoid due to the POLA. It seems inconsistent to me to fix processes that are exactly at the mountpoint directory, but not ones more inside. A possible reason not to handle subdirectories could have been that semantics for that are unclear. But one would have expected some note about that somewhere, given the above. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpfjaLYXUsBs.pgp Description: PGP signature
Re: mount_checkdirs
On Thu 09 Jul 2015 at 00:27:18 +0200, Rhialto wrote: That seems like an inconsistency that we may want to avoid due to the POLA. I may even see an escape from a chroot : 1. process gets chrooted to /altroot 2. it cds into, say, tmp 3. outside, somebody mounts a new system on top of /alroot 4. the process' root gets fixed, but not its cwd 5. cwd is now not inside its root, so successive cd .. escapes to the real root. I gave it a quick try with pkg_comp chroot, the shell it starts, and mounting an install usb stick on top and it didn't work immediately. What I saw in practice with an ls after point 4 was ls: fts_read: operation not permitted so there is some detail that prevents the exact scenario that I tried. But it doesn't seem to be in mount_checkdirs(). It could be something /bin/sh does. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpo3b_YAd2x0.pgp Description: PGP signature
Re: bottom half
On Fri 19 Jun 2015 at 11:45:40 +0200, Edgar Fuß wrote: To eleborate, as I seem to have been too cryptic in my references: I learned the terms top and bottom half from The Design and Implementation of the 4.4BSD Operating System by McKusick, Bostic, Karels and Quaterman. The text on page 51 explains The bottom half of the kernel comprises routines that are invoked to handle hardware interrupts. and the figure 3.1 above explains Never scheduled, cannot block. Runs on kernel stack in kernel address space. For reference: - the same book with 4.3 in the title has the same Figure 3.1, but on page 44. - the same book with FreeBSD in the title has the same Figure 3.1, also on page 51. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpLPiDZFVRHO.pgp Description: PGP signature
Re: Groff
On Thu 04 Jun 2015 at 08:05:16 +0300, Aleksej Saushev wrote: pages to a human-readable and human-writable format, and which is XML, in one sentence... Hahaha! XML and readable? No way. Have you ever seen some document in Docbook? 3. XML can be used immediately, without preprocessing step (just point web browser at it, and it will load stylesheet and perform XSL transformation for you). XSLT is even worse. It is an abomination. XSL is totally unsuited for writing programs. Its notation is completely unreadable and its semantics are incomprehensible. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpr5Lnq4tytd.pgp Description: PGP signature
Re: shipping processes between ttys
On Sun 07 Dec 2014 at 03:25:36 +, David Holland wrote: Somebody mentioned reptyr (https://github.com/nelhage/reptyr) in chat tonight, and so I was thinking about how one might do it properly; this is a topic I've looked at in the past from time to time, so I think I have a viable plan for it. Which I'm going to post, both for feedback and in the hope that I can trick someone into implementing it for me. :-) For a long time I have sort of wanted some variation on this. I wonder if your plan can be generalized in a sensible way to accomplish my idea. Suppose I run some long-running process. It delivers its output to the tty. After a while I realise that this was a mistake; I want the output redirected to a file instead. Killing the process and restarting is not an option (too much time already spent on the task, or whatever). How to do that? The same thing, but the other way around. Or with stdin. In other words, changing the actual files that file descriptors are connected to. Possibly even plumbing a stdout and stdin together with a pipe. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpneMS3nsZro.pgp Description: PGP signature
Re: pserialize(9) vs. TAILQ
On Mon 24 Nov 2014 at 16:56:44 +, Taylor R Campbell wrote: Just to clarify a tiny bit: TAILQ_FOREACH uses data-dependent loads, no matter what CPU architecture it runs on. A data-dependent load is anything like what CPU 2 is doing here: CPU 1 CPU 2 A = 0 A = 5 membar_producer() *pp = A p = *pp v = *p --- Data-dependent load: load address depends on data from previous load. On most CPU architectures, v is guaranteed to be 5; on alpha, if you I must admit that it is not clear to me how on all these architectures the CPU is to know in general that *p depends on p = *pp. I can imagine that this is possible in trivial cases like this, when simply compiled as (let's use PDP-11 syntax) mov _pp,r0 mov (r0),r1 ; r1 is p mov (r1),r2 ; r2 is v but in more complex cases where r1 is moved to another register before indirection, or has some constant or variable added to it or even more complex calculations, this seems far from clear to me. It seems that the Alpha case would actually be more realistic in general. Structs can be very large, so p-far_away_field can address memory quite far away from where p points. Simply discarding a cache line when p is loaded into a register seems neither necessary (-inefficient) nor sufficient. want v to be 5, you must insert a membar_consumer between `p = *pp' and `v = *p'. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpYwaB1qt7OX.pgp Description: PGP signature
Re: Boot wedges
On Sun 23 Nov 2014 at 07:45:13 +1100, matthew green wrote: is this in a manual somewhere? could you make it so if not? :) Speaking of the manual, it suggests that one can put in userconf=disable ethn* commands in boot.cnf. But when I tried it, it didn't seem to work (in a 6.1.5/amd64 system). The device was not disabled (and it needs to be because it hangs the machine in question). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpW8R_AFbfBj.pgp Description: PGP signature
Re: msdosfs and small sectors
On Wed 10 Sep 2014 at 22:53:27 +0100, David Laight wrote: (and ICL system25 whcih wanted 100 byte sectors). Or IBM's CMS which used to have 800 byte sectors. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpfCrsNfWrkg.pgp Description: PGP signature
Re: Making tmpfs reserved memory configurable
On Fri 30 May 2014 at 16:56:01 +0200, Martin Husemann wrote: One open issue is the name - I somehow thought reservee would be a proper noune for reserved memory, but apparently this does not work out well for native speakers, so it probably should be named something else. What about min_ram_free? Other suggestions? I'm not a native speaker either, but it seems reserve (one fewer e) would be good. --- sbin/mount_tmpfs/mount_tmpfs.84 Dec 2013 18:05:21 - 1.17 +++ sbin/mount_tmpfs/mount_tmpfs.830 May 2014 13:42:46 - @@ -83,8 +83,12 @@ Specifies the total file system size in bytes. If zero is given (the default), the available amount of memory (including main memory and swap space) will be used. -Note that four megabytes are always reserved for the system and cannot +Note that some memory (by default: +four megabytes) are always reserved for the system and cannot be assigned to the file system. some memory (...) are - some memory is. I'd split the lines as | Note that some memory | (by default: four megabytes) | is always reserved for the system and cannot -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgprxAEQkY7q7.pgp Description: PGP signature
Re: Lockless IP input queue, the pktqueue interface
On Fri 30 May 2014 at 05:46:37 +1000, matthew green wrote: regardless of how brilliant developers are, i want my code to be written like this anyway. it helps *everyone*. Sometimes I say, on the topic of code, if I don't understand it, it's probably wrong. That's not because I'm so brilliant, but because code should be clear enough to be understood by average programmers. Code is twice as difficult to debug as to write (citation needed!). So if somebody writes brilliantly complex code but it needs to be debugged later, then nobody can do it. And it is still possible that the reason that I don't understand some piece of code is that the author had a mixed up thought process. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpsr5VNMpuDW.pgp Description: PGP signature
Re: amd64 kernel, i386 userland
On Sat 25 Jan 2014 at 17:18:16 +0100, Emmanuel Dreyfus wrote: +an emulation root (e.g.: +.Pa /emul/linux ) That colon doesn't go there. (I see that often, in various languages, and since a colon is (often) pronounced as a change in pitch before it, and a brief pause, it causes a weird sentence. http://www.grammarly.com/handbook/punctuation/colon/5/misuse-of-colon/ seems to give some rules when not to use colons). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpOY8ZsGejl8.pgp Description: PGP signature
Re: in which we present an ugly hack to make sys/queue.h CIRCLEQ work
On Fri 22 Nov 2013 at 11:56:05 +0100, Martin Husemann wrote: On Thu, Nov 21, 2013 at 11:02:24PM -0500, Ken Hornstein wrote: So ... looking at this code ... it seems like the core problem is that TAILQ_HEAD and TAILQ_ENTRY are two different types (even though they literally the same structure layout). So if TAILQ_HEAD and TAILQ_ENTRY were the same structure, it wouldn't be an issue. It doesn't quite leap out to me how that would be possible without changing the API a bit. Right. Let's break the API and fix it for real (which also should cover making it usable for a C++ compiler). Since the tqe_prev field doesn't actually points to the previous object in the list, but to the pointer that points to this object, it is useful for insertion and deletion, but less so for actually finding the previous object. The current TAILQ_PREV essentially goes back 2 steps and then 1 forward (since the forward pointers do point to the objects in the list). I was thinking of something like this, which breaks the API because the current TAILQ_PREV takes 'headname' and not 'type' as a parameter: #defined TAILQ_PREV(elm, type, field) \ (char *)(elm-field.tqe_prev) - offsetof(struct type, field) (omitting outer parentheses and cast to (struct type *) for readability). Similarly for TAILQ_LAST: #defined TAILQ_LAST(elm, type, field) \ (char *)(elm-field.tqe_last) - offsetof(struct type, field) This saves on memory accesses too, compared with the current version. I hope my diagram of how the pointers point was correct :-) Martin -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpXMwYpxlbd8.pgp Description: PGP signature
Re: in which we present an ugly hack to make sys/queue.h CIRCLEQ work
On Wed 20 Nov 2013 at 15:32:20 -0800, Dennis Ferguson wrote: If one were starting this from scratch [...] Ever since I grokked the elegance of Lists in AmigaOS, I've always wondered why other list implementations do it differently. A list is double linked, and it has dummy first and last nodes (which aren't part of the data and consist just of the next and prev pointers). They are elegantly combined in the list header, which consists of 3 pointers: mlh_Headwhich points to the first real node, mlh_Tailwhich is always NULL mlh_TailPredwhich points to the last real node. Each node in the list starts with a ln_Next and a ln_Prev pointer. When the list is empty, mlh_Headpoints to mlh_Tail mlh_Tailis always NULL mlh_TailPredpoints to mlh_Head. The first dummy node consists of mlh_Head and mlh_Tail, i.e. its ln_Prev is NULL, and the last dummy node consists of mlh_Tail and mlh_TailPred, where its ln_Next is NULL. This initially confusing situation eliminates all special cases for node insertion and removal (and traversal isn't made more complicated). This is more extensively explained in http://wiki.amigaos.net/index.php/Exec_Lists_and_Queues . -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpGoRV51t32L.pgp Description: PGP signature
Re: posix_fallocate
On Sun 17 Nov 2013 at 07:59:44 +, David Holland wrote: I think the chief question at this level is whether to support the keep the length flag for fallocate, fdiscard, both, or neither. The What keep the length flag? I don't see one at the indicated URL. The way I read it, the call just fills any holes and/or extends the length of the file. There are no blocks reserved in some magic way That seems to be indicated by the wording If the offset+ len is beyond the current file size, then posix_fallocate() shall adjust the file size to offset+ len. David A. Holland -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpqZgnWVYHkC.pgp Description: PGP signature
Re: posix_fallocate
On Mon 18 Nov 2013 at 05:11:35 +0700, Robert Elz wrote: how does it ever know whether or not there are holes to fill? And why would it do it that way, and follow by fallocate() ? Wasn't there some (proposed? actual?) interface to find holes in files? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpJE4ppPn_az.pgp Description: PGP signature
Re: proposal: some pointer and arithmetic utilities
On Thu 21 Mar 2013 at 18:12:03 +, Taylor R Campbell wrote:
We have various structs of the form
struct foo {
struct bar f_bar;
...
};
and routines that are called like mumble(foo-f_bar) and look like
int
mumble(struct bar *bar)
{
struct foo *foo = (void *)bar;
...
}
which assume that nobody has rearranged the fields of struct foo, an
assumption which is neither semantically significant nor checked by
the compiler; nor does it work with multiple different members from
whose pointers we may want to find the containing object.
I would argue that all such mumble() should really be changed to
int
mumble(struct foo *foo)
{
struct bar *bar = foo-f_bar;
...
}
since they are making that assumption already anyway.
That also works if f_bar isn't the first member in struct foo.
In C++ terms, mumble() is declared with a base class (struct bar) and
assumes it is actually called with a (specific) derived class (struct foo).
That is bad practice there, too.
The only advantage in C++ is that you can have a run-time type check for
it (at a price).
On Thu 21 Mar 2013 at 18:42:16 +, Taylor R Campbell wrote:
/* multiple-evaluation-free roundup2/rounddown2 */
#define roundup2(x, m) x) - 1) | ((m) - 1)) + 1)
That seems to be typeof-free too, so the best of both worlds.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
Temporary IPv6 addresses vs. netgroups
I have set my laptop to use temporary random IPv6 addresses (net.inet6.ip6.use_tempaddr=1). However, it also seems to use those when trying to mount an NFS filesystem. Since NFS is basically authenticated by address, the mount isn't allowed. (So in practice I force it to use IPv4). How can I get some socket(s), in this case those from mount, to use the normally assigned, non-random address? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
Porting FreeBSD drm2 driver
I just noticed that FreeBSD's new 9.1 release has Kernel Mode Setting: The drm2(4) Intel GPU driver, which supports GEM and KMS and works with new generations of GPUs such as IronLake, SandyBridge, and IvyBridge, has been added. The agp(4) driver now supports SandyBridge and IvyBridge CPU northbridges.[r236926, r236927, r239965] (from http://www.freebsd.org/releases/9.1R/relnotes.html) It seems that it is practically impossible to buy a PCI graphics card these days for which X doesn't require KMS. This is going to make the use of NetBSD with X impossible at a very rapid rate. Even the card I that thought was supported properly (Radeon HD 5450-based) isn't - X claims no accelleration. I haven't tried Xv yet (needed to view video) but I fear the worst. Is anybody by any chance working on porting this FreeBSD driver to NetBSD? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
Re: Porting FreeBSD drm2 driver
On Sat 12 Jan 2013 at 16:09:27 +, Christos Zoulas wrote: We are painfully aware of this and we are commissioning work to remedy the situation. Ah, that is great to hear. Thank you! christos -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
Re: [PATCH] fexecve
On Thu 15 Nov 2012 at 20:18:56 -0600, David Young wrote: Label a file descriptor with the root that was in effect when it was created by, say, open(2). The effective root will never change over the lifetime of that descriptor. As devil's advocate: How does this relate to the proposed pivot_root system call? [...] Maybe we can weaken fexecve()'s requirement on the effective root of z to root(z) must be reachable from the effective root, but I think that that might be much more complicated. I believe such a check is already done inside the chroot(2) call so it would be doable. [...] Also, enforcing access along effective roots lines may be inflexible or unwieldy, maybe a more abstract notion of process coalition is better. Let each new root have a corresponding new coalition, but perhaps we should be able to create a new coalition without changing root, and change root without changing coalition. That would make yet another process grouping, confusingly (dis)similar to process groups, controlling-terminal groups, sessions, (and am I forgetting more perhaps?) Dave -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: multiple vnodes for same file?
On Mon 09 Jul 2012 at 06:10:14 +, Emmanuel Dreyfus wrote: Another approach could be to refrain the kernel from reclaiming vnodes that still have children. It seems much simplier. Back in the day when I wrote MSH: (a MSDOS filesystem for the Amiga), I think I did that. (Locks on) Directories refer to (Locks on) their parents, so therefore they contribute to their refcount. Open files own a Lock too, which also refers to its parent directory (Lock), and which therefore also contributes to its refcount. It seems that an AmigaOS Lock is comparable with a vnode. Emmanuel Dreyfus -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: Question about tcp ephemeral ports
On Mon 30 Jan 2012 at 15:39:50 +0100, Olivier MATZ wrote: I would like to have some expert opinions about this behaviour. Is there a workaround? Look into using the socket option SO_REUSEADDR. Regards, Olivier -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: RFC: New bus_space routine: bus_space_sync
On Thu 19 Jan 2012 at 11:16:01 -0800, Matt Thomas wrote: No. Since framebuffers can be considered memory, there is a definite advantage to mapping them cached. Given some gfx cards' gargantuan frame buffers, far bigger than needed for the actual screen contents, isn't there some driver to add that extra memory as extra swap, or something like that? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: PUFFS and existing file that get ENOENT
On Mon 16 Jan 2012 at 13:17:17 +, Emmanuel Dreyfus wrote: But it seems I can lower it from 26214 to 200 without a hitch. I have no idea how mch room it has, however. We cannot get the number of used vnode from userland, can we? pstat -v gives the number of active vnodes; that may be useful. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: Lost file-system story
On Fri 09 Dec 2011 at 17:40:29 -0500, Donald Allen wrote: If I can find the time, I'll do that. Even a little shell script would do: #!/bin/sh while sleep 30; do sync; done -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: Some kernel void functions do return a value
On Sun 16 Oct 2011 at 00:52:35 +0100, Mindaugas Rasiukevicius wrote: David Young dyo...@pobox.com wrote: This isn't just a lint bug? At least two of these are instances of void functions returning the return value of a void function, for which the compiler need neither throw away a value nor create one from whole nothing. The compiler doesn't complain---should it? For example: It has no harm, but C standard does not permit return with an expression for void functions. Compiler throws a warning with -std=c99. Once upon a time, when I was playing with a C compiler, I extended it to have values of type void, including variables. In that variant, you could do what David describes. Of course you could not use void values, only pass them around, which did nothing. But none of that is possible in real C. (The whole exercise started out because I was playing with arrays with 0 elements, which wasn't allowed at the time, but which were often used for open-ended structs) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: A simple cpufreq(9)
On Thu 29 Sep 2011 at 08:50:24 -0400, Mouse wrote: The cache and mmu are probably harder than the cpu :-) I'm not sure the PDP-10 even _had_ cache; I'd have to do some digging on that score. And I have no idea what it had for an MMU. The only I think the MMU differed depending on what operating system you used (TOPS-20 or ITS), or rather the reverse: each OS needed its own particular hardware. And the microcode differed too. non-power-of-two-word-size machine I've ever actually used, as far as I can recall, was a PDP-8. I'm interested in NetBSD/pdp10 less for personal nostalgia value than for the code cleanup it would enforce. It is quite nice actually to play with TOPS-20. It is surprisingly advanced for its time. The Kermit command line interface is modeled after its shell. ITS on the other hand is totally for hackers: its user interface was basically the machine language debugger (DDT) expanded with a few small utility commands. On the other hand, BSD's job control must have been stolen from there, and probably the idea that a command you run is executed in a separate process from the CLI. Via http://panda.com/tops-20/ one can find an emulator and disk image to get started. I actually improved network support in the emulator (klh10-2.0h); I sent patches to the author but the release schedule is a bit slow. SIMH has PDP-10 support; that would probably be a useful resource for anyone taking on a PDP-10 in an FPGA. See http://neil.franklin.ch/Projects/PDP-10/ . Unfinished, unfortunately. /~\ The ASCII Mouse -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: pty(4) 1024 bytes buffer limit
On Thu 08 Sep 2011 at 22:56:29 -0400, Mouse wrote: There's also a possible issue with direct selection data transfer versus INCR data transfer, but in xterm's case that is unlikely to be what's behind your problem. It's hard to be sure; you outline conditions under which you see misbehaviour but you don't say what the misbehaviour actually is. Sorry. What I'm seeing is that I have selected more than 1024 characters in one xterm, and when I paste it in another, I only get the first 1024 of those. The way I checked the number was to type in one shell the wc command, then paste into that xterm. The output from wc (if needed, forced to end with one or two ^Ds) tells me its input is only 1024 bytes. I suddenly realise that the problem could also be on the source side of the paste, because if I paste into a gvim window, the limitation seems to occur too. Though I'm not sure if there isn't a pty in there somewhere too. /~\ The ASCII Mouse -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: pty(4) 1024 bytes buffer limit
I wonder if the pty buffer size is what is limiting my pastes in xterms. I notice them when pasting more than a few text lines (about 23 medium filled lines is the limit in a quick test I just did; wc tells me 1025 characters including an extra newline to terminate the final partial line) into vi inside screen in an xterm, but the limit equally applies if I paste into a wc from stdin directly in an xterm (so screen and vim are not to blame). I'm pretty sure also that in the past there was no such limit, or at least it was much higher. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: Addition to kauth(9) framework
On Mon 29 Aug 2011 at 13:32:50 +0200, Martin Husemann wrote: On Mon, Aug 29, 2011 at 12:13:38PM +0200, Aleksey Cheusov wrote: we will lost our data. Data set by first listerner will be overriden by the second listerner. This is not just waste of time. Yes, but it is a design bug in the modules or in kauth and unrelated to the (un-)sharing, isn't it? My expectation would be that if the first module unshares, the newly unshared data is passed to the second module, who can unshare it again. (I have not looked at code to check if that is what happens, or even if it is easy to make it so) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: autoclean mode for tmpfs
On Sun 07 Aug 2011 at 18:04:43 +0200, Emmanuel Dreyfus wrote: Yes, a TTL attribute on an inode: once it expires, the filesystem tosses the file on next access attempt. If it were done at the next directory listing attempt, it would make more sense (and the removed file should not be reported as present of course). In the mean time, a program which may have created the file and remembered its name, may still access it past the expiration date if it is lucky (i.e., nobody looked - a quantum file system where observation changes the files). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: Adding linux_link(2) system call, second round
On Tue 02 Aug 2011 at 09:05:27 +, Emmanuel Dreyfus wrote: On Tue, Aug 02, 2011 at 10:02:39AM +0100, Roland C. Dowdeswell wrote: It looks like linkat(2) is POSIX.1-2008 and is implemented by Linux as well as FreeBSD. It might be the more portable direction to go. Right, then everything is simple, this is just the matter of implementing a standard system call. Ok, then we also want openat(2), fchmodat(2) (which seems to be misnamed and looks more like a chmodat(2)), unlinkat(2), fchownat(2) (same remark as fchmodat), etc. openat(2) is similar to, but not the same as, the existing function fhopen(2). These functions can be found here too: http://pubs.opengroup.org/onlinepubs/9699919799/functions/func.html FreeBSD seems to have: faccessat fchmodat fchownat fstatat futimesat linkat mkdirat mkfifoat mknodat openat readlinkat renameat symlinkat unlinkat -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: Adding linux_link(2) system call, second round
On Mon 01 Aug 2011 at 10:50:50 +0200, Matthias Drochner wrote: While the DESCRIPTION chapter doesn't tell it explicitely, we have the following in ERRORS: [ELOOP] A loop exists in symbolic links encountered during resolution of the path1 or path2 argument. This implies that the intention is that symlinks are followed. Non-final symlinks are always followed, even for lchmod(2), readlink(2) and similar functions, right? For instance, readlink(2)'s man page also mentions ELOOP. Another argument that allowing hard links to symlinks is only natural: The rename(2) operation does it in any case (on ffs). And one *can* rename symlinks. From /usr/src/sys/ufs/ufs/ufs_vnops.c: /* * Rename vnode operation * rename(foo, bar); * is essentially * unlink(bar); * link(foo, bar); * unlink(foo); * but ``atomically''. Can't do full commit without saving state in the * inode on disk which isn't feasible at this time. Best we can do is * always guarantee the target exists. The code below that doesn't appear to special-case symlinks, only directories. FreeBSD also allows hard links to symlinks, with the ln -P option. (This must have been introduced in version 7 or 8; 6.1 doesn't have it but 8.1 does) LN(1) FreeBSD General Commands Manual LN(1) NAME ln, link -- link files SYNOPSIS ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file [target_file] ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file ... target_dir link source_file target_file DESCRIPTION ... -PWhen creating a hard link to a symbolic link, create a hard link to the symbolic link itself. This option cancels the -L option. test$ ln -s foo bar test$ l total 8 drwxr-xr-x 2 olafs vb 3 Aug 1 12:25 ./ drwxr-xr-x 23 olafs vb 29 Aug 1 12:25 ../ lrwxr-xr-x 1 olafs vb 3 Aug 1 12:25 bar@ - foo test$ ln -P bar baz test$ l total 8 drwxr-xr-x 2 olafs vb 4 Aug 1 12:25 ./ drwxr-xr-x 23 olafs vb 29 Aug 1 12:25 ../ lrwxr-xr-x 2 olafs vb 3 Aug 1 12:25 bar@ - foo lrwxr-xr-x 2 olafs vb 3 Aug 1 12:25 baz@ - foo I tested both on ffs and zfs. The results are the same. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: link(2) on a symlink to a directory fails
On Fri 29 Jul 2011 at 08:12:38 +, Emmanuel Dreyfus wrote: I was trying to track down a bug in glusterfs on NetBSD and encountered a behavior difference between NetBSD and Linux. NetBSD will refuse (EPERM) to link(2) on a symlink to a directory, while Linux is fine with such an operation (but fails to link(2) directly to a directory, just like NetBSD). It seems that if you ln to a symlink, you actually link to the destination of it. There is a -h option for not following symlinks but it is for the target file, not the source file. I'm not sure this makes sense, and I seem to recall vaguely that this was changed in the last few years. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: Dutch keymap not imported into NetBSD :p
On Fri 22 Jul 2011 at 06:26:56 +0200, gilbert.fernan...@orange.fr wrote: Broke my Thinkpad X30 keyboard while being in Germany. Found in a shop a brand new keyboard, told it was German. Turns out it's not German, it's Dutch. That must be very rare! Nobody in their right mind uses a Dutch keyboard. And I say that as a Dutch person. Does it have keys for the italic f (the former currency sign for the guilder (f for florijn but usually called gulden) and for the ij-ligature (ij counts as one letter in Dutch)? (If not, I would not call it a true Dutch keyboard really... my former typewriter had those). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: ioctl(2) vs sys/ioctl.h
On Sun 19 Dec 2010 at 19:32:49 +, David Laight wrote: I suspect the only form that will work is soemthing like: int ioctl(int, unsigned long, void *); #define ioctl(fd, cmd, arg) ioctl(fd, cmd, (void *)(intptr_t)(arg)) Easier: the aforementioned constant FLUSHR (and all others) can be defined as ((void *)1234) (for appropriate values of 1234). However, we don't have streams, so no streams ioctls, which makes the point moot, at least for the given example. David -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: 16 year old bug
On Tue 24 Aug 2010 at 11:10:55 -0400, der Mouse wrote: I believe that non-contiguous netmasks actually are illegal nowadays. Cite? RFC 4632 (CIDR Address Strategy), section 5.1: ...which is titled Rules for Route Advertisement. (Also, 4632 is a BCP, not a standard.) An implementation following these rules should also be generalized, so that an arbitrary network number and mask are accepted for all routing destinations. The only outstanding constraint is that the mask must be left contiguous. With respect to route aggregation in advertisements (ie, exterally-visible behaviour). See the second paragraph of 5.2. Also (thinking perversely), this never says that the 1-bits in the mask must be left-justified... a mask of 0011 1100 has the whole mask contiguous... /~\ The ASCII Mouse -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
