Re: Pending TrustedBSD stuff, etc.

On Fri, 1 Jun 2007, Robert Watson wrote:

>
> On my TODO list still:
>
> (1) Enable audit by default.  Currently I'm working on an patch that moves 
> the
>    per-process audit state into the process credential, which both improves
>    audit performance for threaded apps, and also eliminates an extra memory
>    allocation per process fork.  Once that's reviewed/tested, I'll do the
>    AUDIT enabled by default thing.
>
> (2) Finish eliminating SUSER_ALLOWJAIL.  This is a purely syntactic patch in
>    that SUSER_ALLOWJAIL actually no longer does anything, but it touches a
>    significant percentage of kernel privilege checks, so requires careful
>    testing and review.  This patch is in flight now also.
>
> (3) I might do one more minor OpenBSM import -- no real functional changes,
>    but documentation tweaks and cleanups, especially to the man pages.
>
> Things I would like to see happen, but may not get to:
>
> - For years, several of us have wanted to bump the System V IPC ABI to use
>  full-size uid's, etc.  I laid the groundwork for this in 5.x by starting to
>  divorce the kernel and userspace data structures, but it's never happened.
>  We would provide binary system call compatibility to previous FreeBSD
>  versions, but because as the new API introduces new ABI system calls (etc)
>  it's somewhat disruptive, so can only happen on a major version number
>  change.

You should do it now, but with symbol versioning it doesn't need a version
bump so it could be done anytime after 7.0.

> - Peter Wemm has been talking about moving us to 64-bit inode numbers for
>  years; with the advent of very large file systems and their presumed
>  popularity over the coming 3-5 years, it would be really good to have this
>  in 7.0 or it will have to wait for 8.0.  However, this is quite a 
> disruptive
>  change, as it requires package rebuilds, etc, and we're almost out of time.

The time to do this was a couple of weeks ago when everyone was pretty
much forced to update everything due to xorg, library bumping, symbol
versioning, etc ;-)  Does this change our API/ABI's and how much of
an impact does it have on libc?  If we do it after 7.0, we will have
to add compatibility shims in libc for all interfaces that changed.

-- 
DE