On Tue, 20 May 2025, at 21:17, Billiam Crashkopf wrote:
> Hello all,
>
> I recently had a bit of trouble finding the proper make targets to build
> and install the base FreeBSD system from source into an empty directory
> for use in a jail. I had scoured the build(7) manual trying to find the
>
On Wed, May 21, 2025 at 11:23:12PM +, Brooks Davis wrote:
> On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote:
> > In short, I'd love to widen the interface, but there's a number of practical
> > issues in the way.
>
> I think caching something in the kernel of later retrieval or add
On Fri, May 16, 2025 at 09:21:29PM +0100, Lexi Winter wrote:
i am not sure about this. i admit i have not done a survey :-) however,
i believe most people using jails or bhyve are not affected. the
Handbook is clear about the correct way to configure this[0], so people
who followed the handboo
On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote:
> In short, I'd love to widen the interface, but there's a number of practical
> issues in the way.
I think caching something in the kernel of later retrieval or adding a
new return path to the ABI is the wrong way around. Instead I thi
Brooks Davis writes:
> FWIW, I found it useful that we made SYSERRCAUSE take a format string.
> When debugging complicated mmap usage errors, [...]
The main problem with format strings is that then we need memory
(pre-)allocation.
My proposal gives up that level of precision in favor o
On Wed, May 21, 2025 at 07:22:29AM +, Poul-Henning Kamp wrote:
> The ip# on bridge member interfaces is yet another example of why
> "EINVAL" is the undisputedly least helpful errno of them all.
>
> The laconic "Invalid argument" leaves both the userland programmer
> and the user to guess what
Warner Losh writes:
> In short, I'd love to widen the interface, but there's a number of practical
> issues in the way.
Not really ?
Our kernel is not I18N'ed and we have no plans to do so.
That means that there is absolutely no point in taking a big detour over
enumerating all possibl
On Wed, 21 May 2025 at 10:08, Warner Losh wrote:
The other way to report this would be via something new. There's no new
> register we can report this on in most architectures: they all have
> proscribed
> roles that we can't change (or that would be unwise for use to change).
> There's
> some te
On Wed, May 21, 2025 at 10:23 AM Andriy Gapon wrote:
>
> On 21/05/2025 10:28, Lexi Winter wrote:
> > you are completely right. since we (for some reason, that i don't
> > really understand) can't add new error codes to errno, we should stop
> > using errno to indicate errors except where POSIX re
On 21/05/2025 18:01, void wrote:
This bhyve host was set up following instructions from the bhyve section of the
handbook. I've just checked and no mention is made of the
new requirement in section 24.7.1 of the handbook at
https://freebsd.org/handbook
So, if a lot of people run bhyve guests as
On Wed, May 21, 2025 at 04:44:46PM +0200, Kristof Provost wrote:
[2] because here bge1 has an ip addigned to it and is a bridge member
Yes, that is a problem. Assign REDACTED.REAL.IP to bridge1, not to bge1.
Oof! Thank you for clarifying. I'm glad I asked.
This bhyve host was set up followi
might also want to look at autobridge* options while you redo that config
On 21 May 2025, at 16:40, void wrote:
On Mon, May 19, 2025 at 11:33:50AM +0100, Lexi Winter wrote:
although it's possible everyone who is affected by this is already
aware
of the change, i thought i should send a heads up anyway, if only to
have a single place to discuss this (since there was q
On Mon, May 19, 2025 at 11:33:50AM +0100, Lexi Winter wrote:
although it's possible everyone who is affected by this is already aware
of the change, i thought i should send a heads up anyway, if only to
have a single place to discuss this (since there was quite a lot of
discussion).
in short, fo
On 19/05/25 11:33, Renato Botelho wrote:
Hello!
I have a ThinkPad E14 2nd gen and recenly installed FreeBSD 15-CURRENT
on it. I noticed a problem with lid state not changing and started to
collect more information about it. Here is what I got.
I changed hw.acpi.lid_switch_state to none so
On 2025-05-21 00:22, Poul-Henning Kamp wrote:
The ip# on bridge member interfaces is yet another example of why
"EINVAL" is the undisputedly least helpful errno of them all.
The laconic "Invalid argument" leaves both the userland programmer
and the user to guess what might be wrong.
That's ok-i
Poul-Henning Kamp:
> The ip# on bridge member interfaces is yet another example of why
> "EINVAL" is the undisputedly least helpful errno of them all.
>
> The laconic "Invalid argument" leaves both the userland programmer
> and the user to guess what might be wrong.
you are completely right. si
The ip# on bridge member interfaces is yet another example of why
"EINVAL" is the undisputedly least helpful errno of them all.
The laconic "Invalid argument" leaves both the userland programmer
and the user to guess what might be wrong.
That's ok-ish for read(2) where the possibilities are so fe
18 matches
Mail list logo
