Page MenuHomeFreeBSD

rbranco_suse.com (Ricardo Branco)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 3 2024, 12:44 PM (76 w, 1 d)

Recent Activity

Sat, Jun 14

rbranco_suse.com added a comment to D50703: fcntl.h: warn that bits for O_* flags are scarce.

There's one flag that may need reservation: O_REGULAR, implemented by NetBSD and asked for in Linux in https://github.com/uapi-group/kernel-features

Sat, Jun 14, 5:37 PM
rbranco_suse.com added a comment to D50703: fcntl.h: warn that bits for O_* flags are scarce.

Running out of O_* flag bits will be catastrophic

Why "catastrophic"? We could add an openat2() which takes more flags, like Linux did already. In any case, I do agree that we should be careful about adding new flags.

That might be a bit strong. I'll rephrase. My big worry is that POSIX/Linux add more useful flags and it becomes impossible for us to have source compatibility. I believe Linux has been a less liberal in allocating flag bits so they have a lot more room for growth which adds to the risk. Effectively having to deprecate open() would be a decade+ long project requiring cooperation between all POSIX projects and if we run out of O_ bits first we'll probably lose good will.

openat2 seems generally reasonable except for the bit the glibc doesn't provide bindings which will prove annoying with CHERI compartmentalization where we're not going to allow random code to use __syscall(2).

I wonder what we should do about github.com/freebsd/freebsd-src/pull/1698 then?

I have mixed feelings about it. On one hand it's in POSIX and it provides a certain symmetry. On the other hand, it sounds like Linux won't implement it so it probably shouldn't have been added to POSIX in the first place. I'm more worried about the recent addition of O_NAMEDATTR which is source compatible with nothing (apparently sort of Solaris O_XATTR).

Sat, Jun 14, 3:28 PM

May 27 2024

rbranco_suse.com added a comment to D45305: mqueuefs: remove.
In D45305#1035284, @kib wrote:

There is definitely a memory corruption issue, and from the report, it seems that panic is typically not triggered (immediately).

May 27 2024, 4:13 PM

May 26 2024

rbranco_suse.com added a comment to D45305: mqueuefs: remove.

Now crashing like this:

May 26 2024, 4:29 AM

May 23 2024

rbranco_suse.com added a comment to D45305: mqueuefs: remove.

Still crashes with this fix & commit b6f4a3fa75d24637b4d81035655fcb3d3ea187ad applied.

May 23 2024, 11:14 AM

May 16 2024

rbranco_suse.com added a comment to D45175: SysV IPC: provide in-kernel helpers to obtain ipcs(8)-like information.

I can confirm the patch works as intended.

May 16 2024, 5:39 PM

May 13 2024

rbranco_suse.com added a comment to D45175: SysV IPC: provide in-kernel helpers to obtain ipcs(8)-like information.
In D45175#1030482, @kib wrote:

The native FreeBSD ipcs command also uses these sysctl's.

So what is the problem with native?

May 13 2024, 3:20 PM
rbranco_suse.com added a comment to D45175: SysV IPC: provide in-kernel helpers to obtain ipcs(8)-like information.
In D45175#1030482, @kib wrote:

The native FreeBSD ipcs command also uses these sysctl's.

So what is the problem with native?

May 13 2024, 12:26 PM
rbranco_suse.com added a comment to D45175: SysV IPC: provide in-kernel helpers to obtain ipcs(8)-like information.

The native FreeBSD ipcs command also uses these sysctl's.

May 13 2024, 12:15 PM

Apr 26 2024

rbranco_suse.com added a comment to rGcf04a7775a4e: swapon: Do not overwrite Linux swap header.

I opened a new version at: https://github.com/freebsd/freebsd-src/pull/1205

Apr 26 2024, 6:21 PM

Apr 24 2024

rbranco_suse.com added a comment to rGcf04a7775a4e: swapon: Do not overwrite Linux swap header.

What is the failure on armv7?

Apr 24 2024, 6:31 AM

Feb 22 2024

rbranco_suse.com added a comment to D43990: md5: Fix GNU check mode..

The manpage states:

Feb 22 2024, 8:58 AM

Jan 3 2024

rbranco_suse.com added a comment to D43281: x86: Export cpu_model[].

I successfully tested the patch on a QEMU VM.

Jan 3 2024, 3:18 PM