> OK to violate RFC for performance and simplicity?
I also think the RFC is asking too much (insensitive to the cost on
software routers).
Stuart Henderson wrote:
> The '~' character gets expanded to a random value when the
> .Nm crontab
> is loaded.
Yes.
> "The allowed values for the fields" above misses the various
> possibilities involving ~ too.
It's crazy text, especially the phrase "(within the legal range)" just
loses the
That kind of doesn't matter.
It's the spoofed label. It does not indicate workable IO. The 3
issues together... it smells like an interrupt problem.
ok deraadt
I anticipate no fallout, or very minor and we can handle it then.
Otto Moerbeek wrote:
> On Thu, Jun 20, 2024 at 09:17:38AM +0200, Otto Moerbeek wrote:
>
> > On Wed, Jun 19, 2024 at 06:44:56PM +0200, Theo Buehler wrote:
> >
> > > These are the ports using strmode.
> > >
> > >
Todd C. Miller wrote:
> On Wed, 19 Jun 2024 15:17:05 +0200, Otto Moerbeek wrote:
>
> > Additionally, the implementation in src/libn/libc/string/strmode.c
> > needs to start using mode_t.
> >
> > Building base now with the diff below. So far so good.
> >
> > But this is more tricky you would
I am finding myself in agreement.
Have we decided who will die on the hill?
Ingo Schwarze wrote:
> Not a bug.
> But which one is preferable, test -L or test -h?
>
> TLDR:
> If you follow David Korn, -L is the way to go.
> If you feel nostalgic about old SunOS, -h looks nicer.
> Both were
And the big comment is correct. It may not be this specific chip.
It's this specific chip on this specific machine. Later on we
may know more, to identify the problem better.
Mark Kettenis wrote:
> > Date: Sun, 16 Jun 2024 16:37:10 +
> > From: Klemens Nanni
> >
> > GENERIC cpu(4) fix
ould give clipboard access only to tmux but not the applications
> within it.
>
>
> On 4/18/24 10:14, Theo de Raadt wrote:
> > It is an extremely dangerous anti-feature.
> >
> >> I observed that in OpenBSD 7.5, the configuration of xterm is such that
> >> xtermcfg
It is an extremely dangerous anti-feature.
>I observed that in OpenBSD 7.5, the configuration of xterm is such that
>xtermcfg.h gets #define OPT_PASTE64 0. A consequence of this is that
>OSC 52 support is compiled out, and a consequence of that is that tmux
>cannot set the primary X
Your machine is not actually running 7.5, because your /usr/include
directory has old files.
Kevin wrote:
> Hey gang,
>
> Got the below error when building httpd from source on a bare metal
> Intel Core i7-2600 with 4 CPUs.
>
> Ran the identical command on a virtualized AMD EPYC without
Gibson Pilconis wrote:
> I'm working on a project that supports OpenBSD and I noticed that
> pcidevs_data.h uses
> structures defined in pcireg.h but doesn't include the file. As a result,
> pcireg.h has
> to be included before pcidevs_data.h or else the compiler will throw an
> error.
>
>
You can try booting with:
boot -c
> disable amdgpu0
> quit
That will probably put you into boring vga graphics, you can compile, and
test quickly.
Avon Robertson wrote:
> On Thu, Mar 07, 2024 at 03:50:15PM +1100, Jonathan Gray wrote:
> > Thanks for the detailed report.
> >
> >
Claudio Jeker wrote:
> Thanks for the details. I suggest to commit this so we can get some tests
> quickly and hopefully it helps to fix some of the wg(4) crashes people
> hit. According to your other mail there are some additional races that
> require fixing.
quickly means now, and we have
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Sun, 03 Mar 2024 08:20:33 -0700
> >
> > It almost feels as if libc.so equivelancy should be closer to
> > _dl_find_shlib(),
> >
> > (in particular, meaning searchpath[0] in _dl_
Stuart Henderson wrote:
> +allow dlopen() to search for libc rather than parsing ldconfig -r to
> +decide on a version number.
> +
> +(would this make sense for all libraries? I'm not sure exactly what
> +parameters this might be called with, whether it's just a bare name or
> +could have a
It almost feels as if libc.so equivelancy should be closer to
_dl_find_shlib(),
(in particular, meaning searchpath[0] in _dl_find_shlib() coming
from lpath in _dl_load_shlib()
Is testing for this in loader.c not the right place, and that
code should be moved to a deeper place, reached by more
Stuart Henderson wrote:
> > aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> > (without a specific version number). ld.so is picking the latest and
> > loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> > error.
>
> oh, it's not ld.so which is picking
> aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> (without a specific version number). ld.so is picking the latest and
> loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> error.
Time to explain the msyscall thing a bit.
msyscall(2) will go away after
Sylvain Saboua wrote:
> Le 2024-03-02 21:40, Todd C. Miller a écrit :
> > On Sat, 02 Mar 2024 21:26:23 +0100, Sylvain Saboua wrote:
> >
> >> This works to retrieve and install/update packages as
> >> expected, but I don't get why it should be necessary
> >> since I am not running a release
Is this a situation where two libc's are being loaded into the address
space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc.
We solved that for most programs. Something special about python?
Stuart Henderson wrote:
> On 2024/03/02 20:32, Lucas Gabriel Vuotto wrote:
> > gajim
When a syscall is denied, pledge cannot reverse map the required promise.
It is not possible. Think about it for a bit.
It is best effort. It helps 95% of the developers. When you get close
to ioctl, there is no plausible way to say what promise is required.
cho...@jtan.com wrote:
> I
Please stop sending bug reports as images.
I am pretty much deleting all bug reports from you because they show
no effort on your part.
Kirill A. Korinsky wrote:
> Meanwhile I'd like to add that seems another bug.
>
> I attach two pictures to this message.
> 1. is screenshot of some corner of
No, you can ignore this "warning".
It is unimportant and temporary.
Jacqueline Jolicoeur wrote:
> >Synopsis:amd64 boot reordering warning
> >Category:boot
> >Environment:
> System : OpenBSD 7.5
> Details : OpenBSD 7.5-beta (GENERIC.MP) #25: Sat Feb 24 20:50:14
>
Christian Weisgerber wrote:
> Theo de Raadt:
>
> > Is it mfs specific -- or is it anytime there are layered mountpoints?
>
> Layered mountpoints, it turns out. I can reproduce it by mounting
> another FFS over /usr/obj.
I suspect unveil isn't aware of this situation
Stuart Henderson wrote:
> On 2024/02/19 23:00, hahahahacker2009 wrote:
> > I cannot reproduce the problem with your code
>
> If I mount an MFS /usr/obj *over the top* of an existing FFS /usr/obj
> then I can reproduce it, but not with MFS mounted on /mnt, /mnt/1, /usr/obj/1
Is it mfs specific
Yes, the normal pattern is to update the driver soft state, and
then do perform a backside "down / up" transition.
Stefan Sperling wrote:
> On Sat, Feb 17, 2024 at 06:27:40PM -1000, Todd Carson wrote:
> >
> > On a Raspberry Pi 4 running a recent snapshot, I found that the built-in
> > bwfm
There is no bug.
The distrib directory requires building inside a "full snapshot build" sequence.
Workaround shortcuts can done to make it work, but I will not be adding
workarounds inside the tree to encourage shorcuts, because they will encourage
other fragile breakage. libstubs has
So everyone I should commit both diffs?
Kenneth Westerback wrote:
> Looks correct to me. The value returned by get_ucomnames() is only
> passed to find_ucom() where it is checked against NULL.
Alternative diff in the kernel, *in addition* to the other diff.
On a ucom-supporting kernel, if there are no matching devices the
sysctl
Yes, this code should not fail in that circumstance. It should silently
carry on.
Note the code:
#if NUCOM > 0
case HW_UCOMNAMES: {
If the kernel has no USB com, the sysctl code is disabled. That is why
it MUST silently carry on.
But your bug report is incomplete. Where is the full
Jose Maldonado wrote:
> El Fri, 02 Feb 2024 08:54:58 -0700
> "Theo de Raadt" escribió:
> > tcpdump will *NEVER* be updated to newer code, because our tcpdump is
> > a significant rewrite for privsep. The upstream tcpdump developers
> > don't understand wh
tcpdump will *NEVER* be updated to newer code, because our tcpdump is a
significant rewrite for privsep. The upstream tcpdump developers don't
understand what privsep is.
This means the parsers are run without any permissions. They should
still be correct (so someone will look at this diff),
Todd C. Miller wrote:
> This looks like fallout from the changes in localhost handling in
> the resolver. It seems strange for getaddrinfo() to return success
> but not set res->ai_canonname when AI_CANONNAME is specified.
Setting the actual hostname to "localhost" probably SHOULD result in
What you are asking for is too difficult to do.
netstart is a shell script. shell script arguments are not 8 bit clean,
because the the sh language has many meta & escape characters.
Your configuration exceeds what can be done.
David Gwynne wrote:
> On Wed, Nov 15, 2023 at 06:13:15AM -0700, Theo de Raadt wrote:
> > Luca Di Gregorio wrote:
> >
> > > I'm not sure about this, but I think that public cloud datacenters filter
> > > out
> > > (or do something wi
If you check in your syslog (or console), you will probably see a message
telling you that build_udp_raw() has performed an 'backwards memcpy' which
is not allowed because the result is undefined, therefore we check for this
and then log + abort.
this code should be using memmove().
Rafael
Luca Di Gregorio wrote:
> I'm not sure about this, but I think that public cloud datacenters filter out
> (or do something with) udp traffic to standard udp vxlan port.
But that would not be a reason for allowing selection of the pre-standard
port number.
Rather, it would be a reason for
Stuart Henderson wrote:
> On 2023/11/15 05:59, Theo de Raadt wrote:
> > Otto Moerbeek wrote:
> >
> > > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote:
> > >
> > > > # uname -a
> > > > OpenBSD X.my.domain 7.4
Otto Moerbeek wrote:
> On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote:
>
> > # uname -a
> > OpenBSD X.my.domain 7.4 GENERIC#0 amd64
> >
> > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5
> > # ifconfig vxlan0 inet 192.168.5.1/30
> > # ifconfig vxlan0 up
> >
> >
> It occurred to me later maybe the clock was off?
Oh now people want a ntp client on the installer??!?!
The independent relationships are getting really ridiculous.
Ted Unangst wrote:
> As of this moment, one of the cdn mirrors doesn't work with the installer.
> Whichever lucky one I landed on.
>
> TLS handshake failure: ocsp verify failed: ocsp response not current
>
> This is annoying, and it's not easy to fix while in the installer.
>
> If the cert
Mike Larkin wrote:
> On Sat, Oct 21, 2023 at 01:27:21PM +0400, wes...@technicien.io wrote:
> > Hi Philip,
> >
> > Thank you very much for your answer.
> >
> > I tried to disable all options (+devices) possible. Same issue.
> > And what's about disable acpi in the kernel using the bsd.re-config?
> The project would be better off if you weren't so abrasive to folks
> that honestly want to help things and have real user feedback. I get
> that you may not care, but it is sad to witness.
No, really, you are the one took it abrasive.
I replied with my THOUGHTFUL perpective on why the manual
Oh you hurt my feelings.
However, I am glad you got that off your chest.
Christoff Humphries wrote:
>
>
> --- Original Message ---
> On Monday, October 9th, 2023 at 12:16 PM, Theo de Raadt
> wrote:
> >
> >
> > Christoff Humphries
Christoff Humphries wrote:
> > Marc Espie marc.espie.open...@gmail.com wrote:
> >
> > > On Mon, Oct 09, 2023 at 01:58:27PM +1100, Jonathan Gray wrote:
> > >
> > > > > So tldr: `man backtrace` should name the required linker flag
> > > > > (-lexecinfo)
> > > >
> > > > from mdoc(7):
> > > >
>
Marc Espie wrote:
> On Mon, Oct 09, 2023 at 01:58:27PM +1100, Jonathan Gray wrote:
> > > So tldr: `man backtrace` should name the required linker flag (-lexecinfo)
> >
> > from mdoc(7):
> >
> > .\" .Sh LIBRARY
> > .\" For sections 2, 3, and 9 only.
> > .\" Not used in OpenBSD.
> >
> > note
Cheap broken USB devices not following spec?? Tell me that isn't possible!
:-)
neirac wrote:
> I have a Cirque Corporation, USB GlidePoint, that's not working in 7.3.
> Checking the code I realized that this device is returning 0 as
> bDescriptorType, so I relaxed the error condition to just
Quoting you:
"This condition exists without any hard drive or OS available."
So apparently it has nothing to do with us. Please don't abuse our time.
Chris Bennett wrote:
>
>
> >Synopsis:Boot problems. DP needs conversion to HDMI to get anything on
> >screen
> >Category:system
Rafael Sadowski wrote:
> On Wed Jul 19, 2023 at 02:36:28PM -0600, Theo de Raadt wrote:
> > Rafael Sadowski wrote:
> >
> > > I can reproduce the following panic:
> > >
> > > 1.) Boot
> > > 2.) Start firefox (firefox-115.0.2)
> > >
Rafael Sadowski wrote:
> I can reproduce the following panic:
>
> 1.) Boot
> 2.) Start firefox (firefox-115.0.2)
> 3.) zzz
> 4.) resume and go to the window with firefox
> 5.) panic: kernel diagnostic assertion "flags & (M_WAITOK | M_NOWAIT)"
> failed: file "/usr/src/sys/kern/kern_malloc.c",
Your interpretation is not correct. It is often possible to find old
terms and conditions replaced with newer terms and conditions. Intel
moved away from foolishly restrictive terms and conditions around the
time of the wireless device firmware licensing pressure
>So you personally vouch for the machine code in the official release not
>containing any hidden surprises at present?
I don't vouch for anything, I don't have to. If you don't like it go
scuttle off to someone else who satisfies you.
But your sha256 invocation is going to solve nothing.
>By
"Schech, C. W. (\"Connor\")" wrote:
> I want to avoid derailing into trusting trust or designing a system
> from scratch. The official build not being portable and the recursion
> it introduces is orthogonal to system integrity.. Adding say, official
> distcc support, and bringing back say, GCC
What you are saying makes no sense.
So then the compiler runs to link these binaries, and you trust it?
Also, it is using various libraries, including libc.so, and you have
to trust those files? But those library routines in there trust all sorts
of other files also, to not be corrupted.
By
> We have an annotation we can use during ports build to mark binaries to
> disable enforcement, this will get added to some ports with known
> problems (but I think it maybe a bit problematic when it's a library
> which doesn't yet work with IBT enforcement - in that case AIUI we'll
> need to
Peter N. M. Hansteen wrote:
> On Mon, Jun 12, 2023 at 04:47:41PM +0200, Sebastien Marie wrote:
> > > (gdb)
> > >
> > > with some instruction I might be able to extract more information.
> > >
> >
> > failing in _start is odd. it look like the binary wasn't build with
> >
Yep -- it is definately an old binary.
> failing in _start is odd. it look like the binary wasn't build with
> cf-protection=branch, and the compiler has it since few weeks now (since
> 2023-04-26 exactly).
>
> Could you check the signature date of your package ?
>
> $ grep @digital-signature
Paul de Weerd wrote:
> lpt0 at isa0 port 0x378/4 irq 7
> intr_establish: pic ioapic0 pin 7: can't share type 3 with 2
> wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x52
> vmm0 at mainbus0: SVM/RVI
> acpi.c: acpi_powerdown_task pre prsignal
> acpi.c: acpi_powerdown_task post prsignal
> uhub2 at
Klemens Nanni wrote:
> Snapshots with 'disable inteldrm' to reduce corruption/hangs on a
> Intel T14 gen 3 always print the following on shutdown/reboot:
>
> syncing disks... done
> wsdisplay_switch2: not switching
> rebooting...
>
> Unmodified bsd.mp does not show this.
>
>
A A wrote:
> Hello, Some Linux distros use torrent to distribute installers (such as
> iso file), it will reduce server's capacity and bandwith, and accelerate
> download. Is it possible to use torrent to distribute OpenBSD too? Looking
> forward to your reply!
> Yours,Tom
I do not think
> Well, then the stategy is not to have a strategy, which is perfectly fine.
The strategy is to teach the principle of not over commiting.
> It still doesn't matter for the use case under discussion here. The "bug"
> reporter expected some OOM type situation, and didn't observe any, because
>
Theo de Raadt wrote:
> Rudolf Leitgeb wrote:
>
> > Lots of people (including myself) come from linux background and use
> > OpenBSD for specific security sensitive tasks. Since OpenBSD, like
> > every other desktop OS these days, has some strategy to deal
> >
Rudolf Leitgeb wrote:
> Lots of people (including myself) come from linux background and use
> OpenBSD for specific security sensitive tasks. Since OpenBSD, like
> every other desktop OS these days, has some strategy to deal
> with OOM conditions, the term "OOM killer" is perfectly clear
>
'man boot.conf' shows the boot(8) manual page.
It needs to be written. Other architectures are also missing such a file.
Are you going to write it?
Mike Fischer wrote:
> I have successfully installed a OpenBSD 7.3 arm64 VM on UTM 4.2.5 on a Mac
> mini (2023) with an M2 Pro CPU.
>
> In
Mikolaj Kucharski wrote:
> On Thu, Apr 13, 2023 at 05:18:15PM +, Klemens Nanni wrote:
> > On Thu, Apr 13, 2023 at 04:43:39PM +, Mikolaj Kucharski wrote:
> > > I have an amd64 based cheap laptop, which has extremly slow I/O and even
> > > slower I/O in the installer. The result is, that
Peter J. Philipp wrote:
> On Fri, Apr 14, 2023 at 10:20:39AM -0600, Theo de Raadt wrote:
> > Doctor! Doctor! It hurts when I stick a knife in here!
> >
> > When you do weird, harsh, or unrealistic packet filtering, application
> > software will occasionally log that y
Doctor! Doctor! It hurts when I stick a knife in here!
When you do weird, harsh, or unrealistic packet filtering, application
software will occasionally log that you are losing packets which should
not be filtered, to alert that normal network operation isn't occuring.
That is to be expected. It
No laptop should be that slow. Something is wrong.
If not running the installer, does 'systat vm 1' show interrupt storms
or other root causes?
Or is it only the installer. So the way to debug this is a bit quirky,
I've done this before. It is not simply, I will describe it in small
rough
Your report is complete bullshit.
If /dev/null isn't the right device, then either you were holed by someone who
is trying to mess with you, or your root operator is an idiot.
p...@delphinusdns.org wrote:
> >Synopsis:pledge allows /dev/null to be any file type
> >Category:kernel
>
Peter J. Philipp wrote:
> On Tue, Mar 14, 2023 at 10:34:48AM -0600, Theo de Raadt wrote:
> > Good god, imagine this bit flip happened *anywhere else*, like in the
> > page tables, or in the code or data or stack of chrome, or basically
> > *anywhere*
> >
&
Good god, imagine this bit flip happened *anywhere else*, like in the
page tables, or in the code or data or stack of chrome, or basically
*anywhere*
Shall we change them all?
Shall we change the compiler to not allow checks like this?
Shall we wait for a compiler diff from you?
Using a global variable like that is poor style.
+ if (auth.length > total_length)
Isn't auth.length a network byte order value?
Mark Kettenis wrote:
> I really wonder how these things happen. Cause presumably older
> versions of Windows didn't look at what the DSDT says about the
> polarity, which meant that vendors released DSDTs with the wrong
> polarity. But now Windows does look at what the DSDT says? Does that
>
It should use vis(3), similar to this:
print-pfsync.c: cp = vis(cp, clr->ifname[i], VIS_WHITE, 0);
p...@delphinusdns.org wrote:
> >Synopsis:tcpdump/print-cdp.c allows escape codes to be sent to terminal
> >Category:system
> >Environment:
> System : OpenBSD 7.2
It needs to be fixed in the next 8 hours, or it should be backed out.
> This creates an ABI change. People have to recompile their pfctl.
> I think we never guarantee this level of compatibility.
Correct. It is a binary suppled with the kernel.
We pay attention if it is inconvenient. That means if you need a new
binary before a new kernel. But this is in the
To cross an architecture into xonly [1], there are multiple careful steps,
followed by multiple less careful steps which are required to find the
remaining problem areas.
We have exhausted the careful steps. We are now into the next phase.
[1] Actually, this applies to just about any
Stuart Henderson wrote:
> On 2022/12/19 17:41, Peter Nicolai Mathias Hansteen wrote:
> > > 17. des. 2022 kl. 13:03 skrev Andrey :
> > >
> > >
> > > I need an installation image that immediately, in addition to OpenBSD,
> > > install xfce for me and will automatically launch XFCE when the
That could almost be an entry for calendars.openbsd
Dec 16 Vincent Lefevre arrives and tries to educate the OpenBSD developers
about format string vulnerabilities, which they have been fixing
since 1996
Vincent Lefevre wrote:
> On 2022-12-16 09:03:39 -0700, Theo
Vincent Lefevre wrote:
> BTW, if developers use an untrusted format string, then sprintf()
> is unsafe too (possible buffer overflow), and at some point,
> printf() too.
what are you trying to say?
are you trying to say everyone including you should review and audit and
re-audit all of them?
Well they need to respond, or openbsd ports needs a diff.
Vincent Lefevre wrote:
> On 2022-12-15 18:56:15 -0700, Theo de Raadt wrote:
> > There are almost no %n left in the software ecosystem. If we are able
> > to make this crossing, everyone else is also capable,
This falls into the catagory of "bummer".
We will continue to break all applications that use %n, because we
haven't found a single use of %n is that is safe. and %n uses are
completely trivial to replace.
There are almost no %n left in the software ecosystem. If we are able
to make this
sysctl kern.nosuidcoredump=3
mkdir /var/crash/acme-client
and then try to reproduce, and see if a core file is delivered there.
This coredump mechanism was added to capture some hard-to-capture coredumps,
you can see more info in core(5) and sysctl(3)
Renaud Allard wrote:
> Hi Otto,
>
>
>
This has been fixed.
Miguel Landaeta wrote:
> >Synopsis: riscv64 OpenBSD 7.2 packages are not found at expected URL
> >Category: riscv64
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #188: Wed Sep 28 04:06:11 MDT 2022
>
Your report is innaccurate.
You say 7.1 to 7.2, but you mean 7.2-current
It is a very big difference.
So the problem is that snapshots kernel contains a diff which is ahead the
snapshots build tree, related to the DT_DEBUG change.
I will pull the diff out of snapshots build until the octeon
Klemens Nanni wrote:
> On Fri, Aug 05, 2022 at 07:46:41PM -0700, Michael Truog wrote:
> > On 7/31/22 00:00, Klemens Nanni wrote:
> > > On Sat, Jul 30, 2022 at 06:58:21PM -0700, Michael Truog wrote:
> > > > I previously sent an email regarding the Areca ARC-1880 on sparc64.
> > > > I also have an
Klemens Nanni wrote:
> > GENERIC.MP builds and boots fine with both enabled, but I have no
> > hardware to run-test these drivers.
> >
> > Can anyone test this on real hardware or do we want to just enable it
> > for users to pick up?
> >
> > If that works for Michael, I can build and
> So at some point we need to give up on this pattern of making every
> possible part of the system full configurable.
Precisely.
Like most machines, the APU does very strange things when it has
insufficient Amps.
This situation is more common with APU, because it has an external power
brick.
I've seen this before.
Stuart Henderson wrote:
> On 2022/07/25 23:41, mgra...@brainfat.net wrote:
> > >Description:
> > This change adds the \% argument to the ksh process of the prompt. This
> > will
> > cause the current rdomain of the shell to be displayed in the prompt. This
> > can be quite helpful when
The ramdisk only has the "random" node. All the nodes behave the same.
There is no point in wasting space with another directory reference / inode.
ha...@tutanota.de wrote:
> Hi,
>
> using the shell in the installer, I entered "dd if=/dev/urandom of=/dev/rsd0c
> bs=1m", and the log shows me
Crystal Kolipe wrote:
> On Fri, Jun 10, 2022 at 10:57:49AM -0600, Theo de Raadt wrote:
> > Crystal Kolipe wrote:
> >
> > > On Fri, Jun 10, 2022 at 10:46:28AM -0600, Theo de Raadt wrote:
> > > > Crystal Kolipe wrote:
> > > >
> > > &g
Crystal Kolipe wrote:
> On Fri, Jun 10, 2022 at 10:46:28AM -0600, Theo de Raadt wrote:
> > Crystal Kolipe wrote:
> >
> > > On Fri, Jun 10, 2022 at 06:21:42PM +0200, Claudio Jeker wrote:
> > > > On Fri, Jun 10, 2022 at 11:43:50AM -0400, Andrew Cagney wrote:
Crystal Kolipe wrote:
> On Fri, Jun 10, 2022 at 06:21:42PM +0200, Claudio Jeker wrote:
> > On Fri, Jun 10, 2022 at 11:43:50AM -0400, Andrew Cagney wrote:
> > > On Fri, 10 Jun 2022 at 10:52, Crystal Kolipe
> > > wrote:
> > > >
> > > > On Fri, Jun 10, 2022 at 10:40:47AM -0400, Andrew Cagney
Claudio Jeker wrote:
> On Fri, Jun 10, 2022 at 11:43:50AM -0400, Andrew Cagney wrote:
> > On Fri, 10 Jun 2022 at 10:52, Crystal Kolipe
> > wrote:
> > >
> > > On Fri, Jun 10, 2022 at 10:40:47AM -0400, Andrew Cagney wrote:
> > > > I'm trying to use <> to auto partition a disk
> > > > with most
yes that is the way to do it.
guent...@openbsd.org wrote:
> On Thu, 2 Jun 2022, Luca Di Gregorio wrote:
> > when installing OpenBSD there is the chance to set a network interface,
> > anyway, there is no chance to set the MTU on it.
> >
> > It would be good to add this setting in the
Theo Buehler wrote:
> > I'm not sure if there is much value in percolating the error upwards through
> > tls_init() into a careful termination provides a huge amount of value
> > because
> > the error cannot be resolved without proper build & library support.
>
> Maybe not, but
https://pubs.opengroup.org/onlinepubs/009695299/functions/pthread_once.html
POSIX does not specify that pthread_once() can return ENOSYS. That is a
weird decision to make in libc.
I'm not sure if there is much value in percolating the error upwards through
tls_init() into a careful termination
So this basically converts the flag into a proper reference?
If you go back to 4.4BSD, there's another aspect which was different:
I believe vnodes weren't allocated dynamically, but came out of a fixed
and therefore the recycling behaviour was different. Or maybe some
kernel code had a subtle
1 - 100 of 505 matches
Mail list logo
