The strangeness called `sbin'

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The strangeness called `sbin'

Ed Schouten-3
Hi all,

I suspect this email could be one of the last emails I'm sending before
one of you hire an assassin to get rid of me, but here it goes.

A couple of days ago someone on IRC pointed me to the following
discussion that is taking place at Fedora right now:

        http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus%3D155792

Even though I tend to disagree with Lennart's opinions here and there,
especially on point (h), where he explains there's no advantage of
decomposing the system into a separate / and /usr, I do agree with the
fact that `sbin' is a pretty weird thing.

Nowadays the rule of thumb behind `sbin' is that it contains
applications that are normally only needed by system administrators, but
there are many tools in FreeBSD that contradict this rule:

- md5(1) should be placed in /bin or /usr/bin, while it is stored in
  /sbin. It even has a man page in category 1. Very odd.
- last(1) and w(1) are placed in /usr/bin, while lastlogin(8) and ac(8)
  are placed in /usr/sbin.
- Tools like sysctl(8) and ifconfig(8) are usable by non-root users.
- ...

Now that we're (hopefully) heading into an era where permissions in the
operating systems become more fine-grained, the distinction between bin
and sbin will become even more vague.

Similar to the entire bin <-> sbin thing, I think /usr/games is also a
bit nonsensical, because the games -- including the fortune(6) database
-- only account for about 3.4 MB and FreeBSD 9 will ship with a clang(1)
binary that is a factor 8 or so larger. If people really want to get rid
of the games, they'd be better off running `make delete-old
WITHOUT_GAMES=' in /usr/src after the installation.

My proposal is as follows:

- Move everything in /sbin to /bin and turn it into a symbolic link
  pointing to /bin.
- Move everything in /usr/sbin to /usr/bin and turn it into a symbolic
  link pointing to /usr/bin.
- Move everything in /usr/games to /usr/bin and turn it into a symbolic
  link pointing to /usr/bin.

Just as a test, I wrote a patch that does exactly this. I've attached it
to this email. It would be dangerous to perform such a migration without
any form of approval from the user, the user must perform the migration
manually, using the commands supplied in /usr/src/UPDATING. I have added
an `installcheck' target that prevents a user from running `make
installworld' without performing the migration first.

Do note that this patch makes no attempt to get rid of any other
references to `sbin' in the source tree. In fact, we've got all the time
in the world to get this sorted out, as long as we leave the symlinks in
place.  In fact, I guess we'll never get rid of them anyway, because
almost all pieces of software hardcode strings like
`/usr/sbin/sendmail'.

Well, I think that's all I have to say. I guess I should hide in my
underground lair for now.

--
 Ed Schouten <[hidden email]>
 WWW: http://80386.nl/

nuke-sbin.diff (4K) Download Attachment
attachment1 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Poul-Henning Kamp
In message <[hidden email]>, Ed Schouten writes:

>Nowadays the rule of thumb behind `sbin' is that it contains
>applications that are normally only needed by system administrators,

/sbin was for root in single user mode.

That /usr/sbin/materialized can only be described as a mistake.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Peter Wemm-2
In reply to this post by Ed Schouten-3
On Thu, Nov 10, 2011 at 4:39 AM, Ed Schouten <[hidden email]> wrote:

> Hi all,
>
> I suspect this email could be one of the last emails I'm sending before
> one of you hire an assassin to get rid of me, but here it goes.
>
> A couple of days ago someone on IRC pointed me to the following
> discussion that is taking place at Fedora right now:
>
>        http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus%3D155792
>
> Even though I tend to disagree with Lennart's opinions here and there,
> especially on point (h), where he explains there's no advantage of
> decomposing the system into a separate / and /usr, I do agree with the
> fact that `sbin' is a pretty weird thing.
>
> Nowadays the rule of thumb behind `sbin' is that it contains
> applications that are normally only needed by system administrators, but
> there are many tools in FreeBSD that contradict this rule:
>
> - md5(1) should be placed in /bin or /usr/bin, while it is stored in
>  /sbin. It even has a man page in category 1. Very odd.
> - last(1) and w(1) are placed in /usr/bin, while lastlogin(8) and ac(8)
>  are placed in /usr/sbin.
> - Tools like sysctl(8) and ifconfig(8) are usable by non-root users.
> - ...
>
> Now that we're (hopefully) heading into an era where permissions in the
> operating systems become more fine-grained, the distinction between bin
> and sbin will become even more vague.
>
> Similar to the entire bin <-> sbin thing, I think /usr/games is also a
> bit nonsensical, because the games -- including the fortune(6) database
> -- only account for about 3.4 MB and FreeBSD 9 will ship with a clang(1)
> binary that is a factor 8 or so larger. If people really want to get rid
> of the games, they'd be better off running `make delete-old
> WITHOUT_GAMES=' in /usr/src after the installation.
>
> My proposal is as follows:
>
> - Move everything in /sbin to /bin and turn it into a symbolic link
>  pointing to /bin.
> - Move everything in /usr/sbin to /usr/bin and turn it into a symbolic
>  link pointing to /usr/bin.
> - Move everything in /usr/games to /usr/bin and turn it into a symbolic
>  link pointing to /usr/bin.

[Argh, damn it! I had a huge reply here based on a misunderstanding of
what you were proposing.  I've collected some of the comments that are
still even remotely relevant and tried to correct them, please forgive
any I missed.  I thought you were proposing a symlink farm rather than
linking the dirs.]

There's multiple factors at work, some still relevant, some no longer so.

Once upon a time, there was this thing called $PATH.

For each command you typed at a shell prompt, shells used to do this:

foreach $dir (split(":", $PATH)) {
  execve($dir + $cmd, $args);
}

Indeed, execvp, execlp etc in libc still do precisely this.  The more
pathname components you jammed into $PATH, the more system calls and
file system operations were involved in every single system(), shell
script, etc.

There was also not much in the way of a vfs pathname component cache
back then.  A lookup of a component required scanning directories in
the usual case.  They were usually in the buffer cache, but it still
required scans.  Scanning large directory files took longer than
shorter ones, naturally enough, because it had to iterate across every
entry and do a strcmp().  So, keeping directories smaller sped up
shell scripts.

The bin vs sbin split was done for multiple reasons.  The general rule
was that things that were only interesting or useful to admins, or
required priviliges, or were related to system operation, generally
went into sbin.  There was this other evil thing of putting binaries
in /etc..   eg: /etc/ifconfig, /etc/fsck and horrors like that.  All
of that crap was rounded up into sbin.

The goal for bin was to have it have stuff that was relevant to end
users and shell scripts etc, to make them faster.

Take a random machine and directory contents that VOP_LOOKUP() has to
process on a name cache miss:
bin: 47
sbin: 122
usr/bin: 457
usr/sbin: 266

bin + /usr/bin = 504
bin + sbin + /usr/bin + /usr/sbin: 892


A name cache miss for something at the end of /usr/bin directory file
causes a 504 node scan.  If sbin is merged, that's 892 dirents
scanned, at the worse case.

We do have a decent name cache, but my recent time with it makes me
wonder about a few things.  We do a cache_enter() once we find a vnode
to correspond with a name.  Vnodes have to be resident in order to
have a cached name.  On machines with working sets in the order of
millions of files, I don't imagine the vnodes for /bin and /usr/bin to
hang around too long, and therefore the cache to purge quickly. There
is also UFS_DIRHASH as a band-aid that would minimize the cost of a
bunch of this, for the UFS case.

There is also another user visible effect.  Filename completion in
shells is affected by this.

If I use a shell with a basic user path (_PATH_DEFPATH
"/usr/bin:/bin", which is trashed by login.conf) and hit 'm<tab>', it
offers me 17 possible completions.  If I add both sbin dirs to it,
'm<tab>' turns into 61 options.

Of course, that pales in comparison to the impact of adding
/usr/local/bin to the path, but it does show this does have potential
user visibility.  And there's also the issue that most most users add
every possible directory to their $PATH anyway.

Also.. there is still an extra impact of hitting symlinks.  Suppose a
$PATH has sbin earlier than bin.  execlp("md5", "foo", 0) will find
/sbin/md5 via the symlink before the real binary that moved to
/bin/md5.  Path evaluation would look a little like this (read the
code in vfs_lookup.c:namei()):
VOP_LOOKUP("/sbin/md5")
-> namei() discovers sbin is a link and drops out the end of the loop.
-> namei() does a VOP_READLINK() on sbin in "/", which ufs implements
as an inode open, read, close
-> namei() resets the path to /bin/md5 and jumps back to the top of
the loop and starts again with locking the root vnode and iterating
again to find "bin" in "/"

Having said all that... There are reasons why it was done that way.  I
suspect the costs of the change are something we can eat and will be
lost in other noise in the system.

It's worth keeping in mind though that lots of incremental "small
costs" add up over time when they're done in many many places.

Is it really worth it though?  Perhaps fix the couple of oddball cases
instead? (eg: md5, lastlogin and friends). ac used to require access
to privileged files due to privacy concerns on shared user systems.
--
Peter Wemm - [hidden email]; [hidden email]; [hidden email]; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Ed Schouten-3
Hi Peter,

* Peter Wemm <[hidden email]>, 20111110 17:56:
> Of course, that pales in comparison to the impact of adding
> /usr/local/bin to the path, but it does show this does have potential
> user visibility.  And there's also the issue that most most users add
> every possible directory to their $PATH anyway.

Exactly. Also, there are shells nowadays that cache all binaries in PATH
up front, such as zsh. When they start, they loop through all dirents in
all directories in $PATH and add it to a big cache. This entirely
defeats this purpose.

I don't think that there are that many people who don't add /sbin and
/usr/sbin to $PATH nowadays. I have colleagues of mine who use Linux
systems that don't have this in their $PATH. When I ask them whether it
causes problems for them, they deny, but it turns out they simply put
`sudo' in front of it, to work around that, regardless of whether it was
needed.

> Is it really worth it though?  Perhaps fix the couple of oddball cases
> instead? (eg: md5, lastlogin and friends). ac used to require access
> to privileged files due to privacy concerns on shared user systems.

I think if we have to look at each tool and re-examine whether they
should be in bin or sbin and convert them to do so, it would take
approximately the same amount of investment as moving them into a single
place. And I am willing to do that. :-)

--
 Ed Schouten <[hidden email]>
 WWW: http://80386.nl/

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Peter Wemm-2
On Thu, Nov 10, 2011 at 9:16 AM, Ed Schouten <[hidden email]> wrote:

> Hi Peter,
>
> * Peter Wemm <[hidden email]>, 20111110 17:56:
>> Of course, that pales in comparison to the impact of adding
>> /usr/local/bin to the path, but it does show this does have potential
>> user visibility.  And there's also the issue that most most users add
>> every possible directory to their $PATH anyway.
>
> Exactly. Also, there are shells nowadays that cache all binaries in PATH
> up front, such as zsh. When they start, they loop through all dirents in
> all directories in $PATH and add it to a big cache. This entirely
> defeats this purpose.

I use tcsh and zsh, I'm aware of this cache.

However, libc doesn't, so things like /bin/sh when running shell
scripts do not.  make(1) does not.  People do still care about
buildworld time.  Simple things like changing gcc to static linking
were a few percentage points of buildworld time, back in the day.
Having /bin/sh as a static binary used to be 3%-5% of buildworld time,
simply because fork/exec was faster as the copy-on-write burden was
less.  This stuff adds up.

> I don't think that there are that many people who don't add /sbin and
> /usr/sbin to $PATH nowadays. I have colleagues of mine who use Linux
> systems that don't have this in their $PATH. When I ask them whether it
> causes problems for them, they deny, but it turns out they simply put
> `sudo' in front of it, to work around that, regardless of whether it was
> needed.

Having /sbin in $PATH where /sbin is a symlink to /bin would be worse
than having no /sbin at all, from a perspective of rootvnode lock
lifetime.  If you can figure out how to get people to remove /sbin and
/usr/sbin from their paths after the symlink changes then it becomes a
moot point.  But heck, I still have /usr/X11R6 in mine... :(

--
Peter Wemm - [hidden email]; [hidden email]; [hidden email]; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Warner Losh
In reply to this post by Ed Schouten-3
On Nov 10, 2011, at 10:16 AM, Ed Schouten wrote:

> Hi Peter,
>
> * Peter Wemm <[hidden email]>, 20111110 17:56:
>> Of course, that pales in comparison to the impact of adding
>> /usr/local/bin to the path, but it does show this does have potential
>> user visibility.  And there's also the issue that most most users add
>> every possible directory to their $PATH anyway.
>
> Exactly. Also, there are shells nowadays that cache all binaries in PATH
> up front, such as zsh. When they start, they loop through all dirents in
> all directories in $PATH and add it to a big cache. This entirely
> defeats this purpose.

tcsh and csh before it has been doing this since the 1980's, so it is nothing new.  Add a new binary to your path and forget to rehash: you can't run it.

> I don't think that there are that many people who don't add /sbin and
> /usr/sbin to $PATH nowadays. I have colleagues of mine who use Linux
> systems that don't have this in their $PATH. When I ask them whether it
> causes problems for them, they deny, but it turns out they simply put
> `sudo' in front of it, to work around that, regardless of whether it was
> needed.

Folks that grew up before the "all the world is a vax^W^Wruns Linux" have it in their path, but younger colleges generally don't have it unless they've been forced to use Solaris or *BSD at some point.

>> Is it really worth it though?  Perhaps fix the couple of oddball cases
>> instead? (eg: md5, lastlogin and friends). ac used to require access
>> to privileged files due to privacy concerns on shared user systems.
>
> I think if we have to look at each tool and re-examine whether they
> should be in bin or sbin and convert them to do so, it would take
> approximately the same amount of investment as moving them into a single
> place. And I am willing to do that. :-)

I'm a bit torn here.  It would be nice to have one, unified place for binaries.  Do embedded systems really need to burn the extra inodes on sbin, libexec, etc?  No, they don't.  On the other hand, these paths seep into so many places that I gave up my attempts years ago to just put all the files in one place (I didn't like the symlink idea because I worried about shells that were stupid and put all entires into their hashes multiple times).

I'd honestly start small here with (1) move the ones that are obviously wrong (and aren't specified by posix to be wrong). (2) make it an option to just make one or two binaries directories with compat symlinks (because there's a ton of scripts that just know where binaries life).

Warner_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Ed Schouten-3
In reply to this post by Peter Wemm-2
* Peter Wemm <[hidden email]>, 20111110 18:33:
> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse
> than having no /sbin at all, from a perspective of rootvnode lock
> lifetime.  If you can figure out how to get people to remove /sbin and
> /usr/sbin from their paths after the symlink changes then it becomes a
> moot point.  But heck, I still have /usr/X11R6 in mine... :(

On the other hand, if people used to have /sbin in their path and *do*
remove it properly after the upgrade, they should in theory see a
performance improvement, right?

Assume $PATH used to be /bin:/sbin:/usr/bin:/usr/sbin:/usr/games:... and
is switched to /bin:/usr/bin:... after the upgrade. Now if somebody
tries to execute something that's not part of the base system, then it
would require at least 3 calls to execve(), whereas in our current setup
it would require 6 system calls.

Therefore I think it's hard to say anything conclusive about performance
in this area.

--
 Ed Schouten <[hidden email]>
 WWW: http://80386.nl/

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Garrett Cooper
On Thu, Nov 10, 2011 at 9:47 AM, Ed Schouten <[hidden email]> wrote:

> * Peter Wemm <[hidden email]>, 20111110 18:33:
>> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse
>> than having no /sbin at all, from a perspective of rootvnode lock
>> lifetime.  If you can figure out how to get people to remove /sbin and
>> /usr/sbin from their paths after the symlink changes then it becomes a
>> moot point.  But heck, I still have /usr/X11R6 in mine... :(
>
> On the other hand, if people used to have /sbin in their path and *do*
> remove it properly after the upgrade, they should in theory see a
> performance improvement, right?

    Doesn't the negative directory cache (namei, etc) mitigate this?
Thanks!
-Garrett
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Ed Schouten-3
* Garrett Cooper <[hidden email]>, 20111110 19:12:

> On Thu, Nov 10, 2011 at 9:47 AM, Ed Schouten <[hidden email]> wrote:
> > * Peter Wemm <[hidden email]>, 20111110 18:33:
> >> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse
> >> than having no /sbin at all, from a perspective of rootvnode lock
> >> lifetime.  If you can figure out how to get people to remove /sbin and
> >> /usr/sbin from their paths after the symlink changes then it becomes a
> >> moot point.  But heck, I still have /usr/X11R6 in mine... :(
> >
> > On the other hand, if people used to have /sbin in their path and *do*
> > remove it properly after the upgrade, they should in theory see a
> > performance improvement, right?
>
>     Doesn't the negative directory cache (namei, etc) mitigate this?
Peter is also talking about the fact that if you have a PATH like
/bin:/sbin:... and /sbin is a symbolic link to /bin, you end up doing
this:

        execve("/bin/YOURAPP", ...) -> fails
        execve("/sbin/YOURAPP", ...) -> fails
        ...
        execve("/some/other/directory/YOURAPP", ...) -> success

The first two system calls together are expected to be slightly slower
than they used to be, because both these directories have now grown.

--
 Ed Schouten <[hidden email]>
 WWW: http://80386.nl/

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Ed Schouten-3
In reply to this post by Warner Losh
Hello Warner,

* Warner Losh <[hidden email]>, 20111110 18:38:
> I'd honestly start small here with (1) move the ones that are
> obviously wrong (and aren't specified by posix to be wrong). (2) make
> it an option to just make one or two binaries directories with compat
> symlinks (because there's a ton of scripts that just know where
> binaries life).

POSIX doesn't care about specific pathnames that much. According to the
spec, only /, /dev, /dev/{console,null,tty} and /tmp are reserved. The
rest can be arranged the way you like.

The problem is that both proposals (being mine vs. the first option you
mentioned) have regressions in some way or another:

- Merging sbin with bin may potentially make stuff slower, because of
  redundant PATH lookups, under the assumption that people don't update
  their PATH.

- Moving utilities from /usr/sbin to /usr/bin and vice versa can
  potentially cause even more breakage, since 3rd party applications
  may depend on their location. Even worse: if people don't properly run
  `make delete-old', they end up having multiple versions of the binary
  installed on their system.

A few symlinks here and there isn't that bad. If we just make sure our
base system can eventually work without them, most embedded systems can
do so as well.

--
 Ed Schouten <[hidden email]>
 WWW: http://80386.nl/

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Garrett Wollman-7
In reply to this post by Warner Losh
In article <[hidden email]>,
Warner Losh writes:

>I'd honestly start small here with (1) move the ones that are obviously
>wrong (and aren't specified by posix to be wrong).

POSIX doesn't specify paths for utilities.  (The only paths specified
by POSIX are "/dev/tty" and "/dev/null", and it doesn't require that
"/dev" actually exist.)

-GAWollman

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Peter Wemm-2
In reply to this post by Garrett Cooper
On Thu, Nov 10, 2011 at 10:12 AM, Garrett Cooper <[hidden email]> wrote:

> On Thu, Nov 10, 2011 at 9:47 AM, Ed Schouten <[hidden email]> wrote:
>> * Peter Wemm <[hidden email]>, 20111110 18:33:
>>> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse
>>> than having no /sbin at all, from a perspective of rootvnode lock
>>> lifetime.  If you can figure out how to get people to remove /sbin and
>>> /usr/sbin from their paths after the symlink changes then it becomes a
>>> moot point.  But heck, I still have /usr/X11R6 in mine... :(
>>
>> On the other hand, if people used to have /sbin in their path and *do*
>> remove it properly after the upgrade, they should in theory see a
>> performance improvement, right?
>
>    Doesn't the negative directory cache (namei, etc) mitigate this?
> Thanks!

Yes, the negative cache entries in the name cache should help.

You know, we have very good tools to characterize the effects on
this.. see ministat(1).

I'd be interested to see if the effects are worth worrying about on things like:

repeated shell startup (think: system(3)), or sh -c "somecommand"
buildworld time
runtime of non-trivial shell scripts, eg: configure, perl Configure etc
runtime of other some perl scripts that have a bunch of system() or
`cmd` all over the damn place.

.. all with and without optimal $PATHs and bad $PATHs.

The one that I can't think of a good way to characterize would be
systemic effects on rootvnode locking from hitting a /sbin->/bin
symlink.  That's harder to measure because it affects other users of
the system than the item under test.

Even things like sh -c "command" is hard to measure because it'll hit
the name cache with 100% success and won't test the cache miss cases.

--
Peter Wemm - [hidden email]; [hidden email]; [hidden email]; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Garrett Cooper
On Thu, Nov 10, 2011 at 10:43 AM, Peter Wemm <[hidden email]> wrote:

> On Thu, Nov 10, 2011 at 10:12 AM, Garrett Cooper <[hidden email]> wrote:
>> On Thu, Nov 10, 2011 at 9:47 AM, Ed Schouten <[hidden email]> wrote:
>>> * Peter Wemm <[hidden email]>, 20111110 18:33:
>>>> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse
>>>> than having no /sbin at all, from a perspective of rootvnode lock
>>>> lifetime.  If you can figure out how to get people to remove /sbin and
>>>> /usr/sbin from their paths after the symlink changes then it becomes a
>>>> moot point.  But heck, I still have /usr/X11R6 in mine... :(
>>>
>>> On the other hand, if people used to have /sbin in their path and *do*
>>> remove it properly after the upgrade, they should in theory see a
>>> performance improvement, right?
>>
>>    Doesn't the negative directory cache (namei, etc) mitigate this?
>> Thanks!
>
> Yes, the negative cache entries in the name cache should help.
>
> You know, we have very good tools to characterize the effects on
> this.. see ministat(1).
>
> I'd be interested to see if the effects are worth worrying about on things like:
>
> repeated shell startup (think: system(3)), or sh -c "somecommand"
> buildworld time
> runtime of non-trivial shell scripts, eg: configure, perl Configure etc
> runtime of other some perl scripts that have a bunch of system() or
> `cmd` all over the damn place.
>
> .. all with and without optimal $PATHs and bad $PATHs.
>
> The one that I can't think of a good way to characterize would be
> systemic effects on rootvnode locking from hitting a /sbin->/bin
> symlink.  That's harder to measure because it affects other users of
> the system than the item under test.
>
> Even things like sh -c "command" is hard to measure because it'll hit
> the name cache with 100% success and won't test the cache miss cases.

gnn / Professor McKusick's book -- the Design and Implementation of
FreeBSD -- suggests that this is an optimal method, but the benchmarks
were run some time ago and hardware has changed. I think that
rerunning the benchmarks on i386 vs amd64 vs {arm,mips,etc} would
definitely be a good idea.

Thanks!
-Garrett
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Ed Schouten-3
* Garrett Cooper <[hidden email]>, 20111110 20:05:
> gnn / Professor McKusick's book -- the Design and Implementation of
> FreeBSD -- suggests that this is an optimal method, but the benchmarks
> were run some time ago and hardware has changed. I think that
> rerunning the benchmarks on i386 vs amd64 vs {arm,mips,etc} would
> definitely be a good idea.

Be my guest. :-)

--
 Ed Schouten <[hidden email]>
 WWW: http://80386.nl/

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

dougb
In reply to this post by Ed Schouten-3
On 11/10/2011 04:39, Ed Schouten wrote:
> I suspect this email could be one of the last emails I'm sending before
> one of you hire an assassin to get rid of me, but here it goes.

Au contraire, I think your work on improving the general quality of our
code has earned you many many brownie points, so you're far from being
run out of town on a rail. :)

This particular proposal though I personally am confused about, and I
apologize if I missed something obvious, but what is the value of making
this change? I've read the thread so far, and I understand that the
hysterical raisins that prompted the creation of sbin may or may not
still apply, but I haven't yet understood what we would gain by moving
everything.


Sorry if I'm being dense,

Doug

--

                "We could put the whole Internet into a book."
                "Too practical."

        Breadth of IT experience, and depth of knowledge in the DNS.
        Yours for the right price.  :)  http://SupersetSolutions.com/

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Mark Andrews-4
In reply to this post by Garrett Cooper

If we want to fix thing make any port the replicates anything in
the base system install itself into its own heirachy.  Installing
into /usr/local make it impossible to select different version on
a per user basis.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Andrew Lankford
In reply to this post by Ed Schouten-3
 >- Move everything in /usr/games to /usr/bin and turn it into a symbolic
   link pointing to /usr/bin.

No no no....move all or 99.9% of /usr/games to ports/games or
ports/math.  Then put an unencumbered ascii-graphics mode version of
Quake 3 in /usr/bin.  Perfection!

Andrew Lankford
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Ed Schouten-3
In reply to this post by Peter Wemm-2
Hi Peter,

* Peter Wemm <[hidden email]>, 20111110 19:43:
> repeated shell startup (think: system(3)), or sh -c "somecommand"

I have done some testing and it seems we have little to worry about, in
my opinion. I have written a small script that copies the `true' binary
to each of the directories specified in $PATH and executes it 100.000
times. I have executed these tests on an installation where sbin is
still separate and one where it is merged. Also, I've used both a $PATH
variable that contains /sbin and one where it is removed.

Observations:
- Indeed, the running time increases when the binary to be executed is
  in a directory that is placed farther to the end of $PATH.
- Redundant directories in $PATH do cause some overhead.
- When we merge sbin with bin and the user properly removes sbin from
  his/her PATH variable, things get slightly faster than they used to
  be.
- When the user forgets to do so, the results are slightly worse than
  before.

Of course, this was just a quick way of testing things. If people want
to do more thorough tests, be my guest. I have attached an updated
version of my patch, the script I used to do the benchmark and the
results I have obtained.

--
 Ed Schouten <[hidden email]>
 WWW: http://80386.nl/

nuke-sbin.diff (19K) Download Attachment
bench-results.txt (1K) Download Attachment
attachment2 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Ed Schouten-3
In reply to this post by dougb
Hello Doug,

* Doug Barton <[hidden email]>, 20111110 23:08:
> On 11/10/2011 04:39, Ed Schouten wrote:
> > I suspect this email could be one of the last emails I'm sending before
> > one of you hire an assassin to get rid of me, but here it goes.
>
> Au contraire, I think your work on improving the general quality of our
> code has earned you many many brownie points, so you're far from being
> run out of town on a rail. :)

Thanks. :-)

> This particular proposal though I personally am confused about, and I
> apologize if I missed something obvious, but what is the value of making
> this change? I've read the thread so far, and I understand that the
> hysterical raisins that prompted the creation of sbin may or may not
> still apply, but I haven't yet understood what we would gain by moving
> everything.

Simplicity. Right now we have binaries executed by users installed in
five different places. I give bachelor courses on (embedded)
Linux/FreeBSD systems administration and software development and
explaining to them why it is done this way is getting tiresome.

But the point is: there are quite some tools in */sbin that should be
moved to */bin. I can at least point out 15 of them. Moving these tools
around requires the same amount of effort as simply getting rid of sbin.
If I have to decide on which of these to work, I'd choose the latter,
because as far as I know, sbin has no reason to exist anyway.

Also, it probably causes even less of a burden on our users, because
`make installworld' will simply force them to migrate, while if we move
binaries around, we can only hope that the user runs `make delete-old'.

--
 Ed Schouten <[hidden email]>
 WWW: http://80386.nl/

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The strangeness called `sbin'

Gleb Kurtsou-3
In reply to this post by Ed Schouten-3
On (11/11/2011 11:46), Ed Schouten wrote:

> Hi Peter,
>
> * Peter Wemm <[hidden email]>, 20111110 19:43:
> > repeated shell startup (think: system(3)), or sh -c "somecommand"
>
> I have done some testing and it seems we have little to worry about, in
> my opinion. I have written a small script that copies the `true' binary
> to each of the directories specified in $PATH and executes it 100.000
> times. I have executed these tests on an installation where sbin is
> still separate and one where it is merged. Also, I've used both a $PATH
> variable that contains /sbin and one where it is removed.

It's not clear if you used sbin symlinks in tests, no script attached.

It's VOP_READLINK overhead we should care about. All entries (incl
negative cache) will be cached by VFS under bin/. I presume difference
to be negligible and support the change.

sbin/something lookup:
vp0 = VOP_LOOKUP(sbin) (may be cached)
VOP_READLINK(vp0)
vp1 = VOP_LOOKUP(bin) (may be cached)
vp2 = VOP_LOOKUP(something) (may be cached)

>
> Observations:
> - Indeed, the running time increases when the binary to be executed is
>   in a directory that is placed farther to the end of $PATH.
> - Redundant directories in $PATH do cause some overhead.
> - When we merge sbin with bin and the user properly removes sbin from
>   his/her PATH variable, things get slightly faster than they used to
>   be.
> - When the user forgets to do so, the results are slightly worse than
>   before.
>
> Of course, this was just a quick way of testing things. If people want
> to do more thorough tests, be my guest. I have attached an updated
> version of my patch, the script I used to do the benchmark and the
> results I have obtained.
>
> --
>  Ed Schouten <[hidden email]>
>  WWW: http://80386.nl/

> Index: secure/usr.sbin/Makefile.inc
> ===================================================================
> --- secure/usr.sbin/Makefile.inc (revision 227417)
> +++ secure/usr.sbin/Makefile.inc (working copy)
> @@ -1,5 +1,5 @@
>  # $FreeBSD$
>  
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  .include "../Makefile.inc"
> Index: games/Makefile.inc
> ===================================================================
> --- games/Makefile.inc (revision 227417)
> +++ games/Makefile.inc (working copy)
> @@ -1,7 +1,7 @@
>  # @(#)Makefile.inc 8.1 (Berkeley) 5/31/93
>  # $FreeBSD$
>  
> -BINDIR?= /usr/games
> +BINDIR?= /usr/bin
>  FILESDIR?= ${SHAREDIR}/games
>  WARNS?= 6
>  DISTRIBUTION?= games
> Index: tools/tools/cxgbtool/Makefile
> ===================================================================
> --- tools/tools/cxgbtool/Makefile (revision 227417)
> +++ tools/tools/cxgbtool/Makefile (working copy)
> @@ -5,6 +5,6 @@
>  NO_MAN=
>  CFLAGS+= -I${.CURDIR}/../../../sys/dev/cxgb -I.
>  CFLAGS+= -DCONFIG_T3_REGS -DCHELSIO_INTERNAL
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  .include <bsd.prog.mk>
> Index: tools/tools/vimage/Makefile
> ===================================================================
> --- tools/tools/vimage/Makefile (revision 227417)
> +++ tools/tools/vimage/Makefile (working copy)
> @@ -9,6 +9,6 @@
>  
>  MAN= vimage.8
>  
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  .include <bsd.prog.mk>
> Index: tools/tools/cxgbetool/Makefile
> ===================================================================
> --- tools/tools/cxgbetool/Makefile (revision 227417)
> +++ tools/tools/cxgbetool/Makefile (working copy)
> @@ -4,6 +4,6 @@
>  SRCS= cxgbetool.c
>  NO_MAN=
>  CFLAGS+= -I${.CURDIR}/../../../sys/dev/cxgbe -I.
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  .include <bsd.prog.mk>
> Index: kerberos5/usr.sbin/Makefile.inc
> ===================================================================
> --- kerberos5/usr.sbin/Makefile.inc (revision 227417)
> +++ kerberos5/usr.sbin/Makefile.inc (working copy)
> @@ -1,5 +1,5 @@
>  # $FreeBSD$
>  
> -BINDIR= /usr/sbin
> +BINDIR= /usr/bin
>  
>  .include "../Makefile.inc"
> Index: share/man/man7/hier.7
> ===================================================================
> --- share/man/man7/hier.7 (revision 227417)
> +++ share/man/man7/hier.7 (working copy)
> @@ -145,8 +145,6 @@
>  .It Pa /lib/
>  critical system libraries needed for binaries in
>  .Pa /bin
> -and
> -.Pa /sbin
>  .Pp
>  .Bl -tag -width ".Pa geom/" -compact
>  .It Pa geom/
> @@ -157,8 +155,6 @@
>  .It Pa /libexec/
>  critical system utilities needed for binaries in
>  .Pa /bin
> -and
> -.Pa /sbin
>  .It Pa /media/
>  contains subdirectories to be used as mount points
>  for removable media such as CDs, USB drives, and
> @@ -176,9 +172,6 @@
>  .Xr rescue 8
>  .It Pa /root/
>  root's HOME directory
> -.It Pa /sbin/
> -system programs and administration utilities
> -fundamental to both single-user and multi-user environments
>  .It Pa /tmp/
>  temporary files that are not guaranteed to persist across system reboots
>  .It Pa /usr/
> @@ -192,8 +185,6 @@
>  such as Linux
>  (created by
>  .Xr sysinstall 8 )
> -.It Pa games/
> -useful and semi-frivolous programs
>  .It Pa include/
>  standard C include files
>  .Pp
> @@ -462,8 +453,6 @@
>  The
>  .Fx
>  ports collection (optional).
> -.It Pa sbin/
> -system daemons & system utilities (executed by users)
>  .It Pa share/
>  architecture-independent files
>  .Pp
> @@ -645,8 +634,6 @@
>  source code for contributed cryptography software
>  .It Pa etc/
>  source code for files in /etc
> -.It Pa games/
> -source code for files in /usr/games
>  .It Pa gnu/
>  Utilities covered by the GNU General Public License
>  .It Pa include/
> @@ -661,8 +648,6 @@
>  files required to produce a
>  .Fx
>  release
> -.It Pa sbin/
> -source code for files in /sbin
>  .It Pa secure/
>  build directory for files in /usr/src/crypto
>  .It Pa share/
> @@ -674,8 +659,6 @@
>  .Fx
>  .It Pa usr.bin/
>  source code for files in /usr/bin
> -.It Pa usr.sbin/
> -source code for files in /usr/sbin
>  .El
>  .El
>  .It Pa /var/
> Index: usr.sbin/tcpdump/Makefile.inc
> ===================================================================
> --- usr.sbin/tcpdump/Makefile.inc (revision 227417)
> +++ usr.sbin/tcpdump/Makefile.inc (working copy)
> @@ -1,6 +1,6 @@
>  # @(#)Makefile.inc 5.1 (Berkeley) 5/11/90
>  # $FreeBSD$
>  
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  WARNS?= 3
> Index: usr.sbin/Makefile.inc
> ===================================================================
> --- usr.sbin/Makefile.inc (revision 227417)
> +++ usr.sbin/Makefile.inc (working copy)
> @@ -1,6 +1,6 @@
>  # @(#)Makefile.inc 8.1 (Berkeley) 6/6/93
>  # $FreeBSD$
>  
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  WARNS?= 6
> Index: usr.sbin/bootparamd/Makefile.inc
> ===================================================================
> --- usr.sbin/bootparamd/Makefile.inc (revision 227417)
> +++ usr.sbin/bootparamd/Makefile.inc (working copy)
> @@ -1,6 +1,6 @@
>  # @(#)Makefile.inc 5.1 (Berkeley) 5/11/90
>  # $FreeBSD$
>  
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  WARNS?= 2
> Index: usr.sbin/wpa/Makefile.inc
> ===================================================================
> --- usr.sbin/wpa/Makefile.inc (revision 227417)
> +++ usr.sbin/wpa/Makefile.inc (working copy)
> @@ -1,6 +1,6 @@
>  # $FreeBSD$
>  
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  WPA_DISTDIR?= ${.CURDIR}/../../../contrib/wpa/
>  WPA_SUPPLICANT_DISTDIR?=${WPA_DISTDIR}/wpa_supplicant
> Index: usr.sbin/mailwrapper/Makefile
> ===================================================================
> --- usr.sbin/mailwrapper/Makefile (revision 227417)
> +++ usr.sbin/mailwrapper/Makefile (working copy)
> @@ -11,11 +11,11 @@
>  .endif
>  
>  .if ${MK_MAILWRAPPER} != "no" || ${MK_SENDMAIL} != "no"
> -SYMLINKS= ${BINDIR}/mailwrapper /usr/sbin/sendmail  \
> - ${BINDIR}/mailwrapper /usr/sbin/hoststat  \
> - ${BINDIR}/mailwrapper /usr/sbin/purgestat \
> - ${BINDIR}/mailwrapper /usr/bin/newaliases \
> - ${BINDIR}/mailwrapper /usr/bin/mailq
> +SYMLINKS= mailwrapper ${BINDIR}/sendmail  \
> + mailwrapper ${BINDIR}/hoststat  \
> + mailwrapper ${BINDIR}/purgestat \
> + mailwrapper ${BINDIR}/newaliases \
> + mailwrapper ${BINDIR}/mailq
>  
>  .if ${MK_MAILWRAPPER} == "no" && ${MK_SENDMAIL} != "no"
>  SYMLINKS+= /usr/libexec/sendmail/sendmail ${BINDIR}/mailwrapper
> Index: usr.sbin/nologin/Makefile
> ===================================================================
> --- usr.sbin/nologin/Makefile (revision 227417)
> +++ usr.sbin/nologin/Makefile (working copy)
> @@ -4,7 +4,7 @@
>  PROG= nologin
>  MAN= nologin.5 nologin.8
>  
> -SYMLINKS= ${BINDIR}/nologin /sbin/nologin
> +SYMLINKS= ${BINDIR}/nologin /bin/nologin
>  
>  # It is important that nologin be statically linked for security
>  # reasons.  A dynamic non-setuid binary can be linked against a trojan
> Index: include/paths.h
> ===================================================================
> --- include/paths.h (revision 227417)
> +++ include/paths.h (working copy)
> @@ -38,9 +38,9 @@
>  /* Default search path. */
>  #define _PATH_DEFPATH "/usr/bin:/bin"
>  /* All standard utilities path. */
> -#define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin"
> +#define _PATH_STDPATH "/usr/bin:/bin"
>  /* Locate system binaries. */
> -#define _PATH_SYSPATH "/sbin:/usr/sbin"
> +#define _PATH_SYSPATH "/bin:/usr/bin"
>  
>  #define _PATH_AUTHCONF "/etc/auth.conf"
>  #define _PATH_BSHELL "/bin/sh"
> @@ -58,31 +58,31 @@
>  #define _PATH_ETC "/etc"
>  #define _PATH_FTPUSERS "/etc/ftpusers"
>  #define _PATH_FWMEM "/dev/fwmem"
> -#define _PATH_HALT "/sbin/halt"
> +#define _PATH_HALT "/bin/halt"
>  #ifdef COMPAT_32BIT
>  #define _PATH_I18NMODULE "/usr/lib32/i18n"
>  #else
>  #define _PATH_I18NMODULE "/usr/lib/i18n"
>  #endif
> -#define _PATH_IFCONFIG "/sbin/ifconfig"
> +#define _PATH_IFCONFIG "/bin/ifconfig"
>  #define _PATH_KMEM "/dev/kmem"
>  #define _PATH_LIBMAP_CONF "/etc/libmap.conf"
>  #define _PATH_LOCALE "/usr/share/locale"
>  #define _PATH_LOGIN "/usr/bin/login"
>  #define _PATH_MAILDIR "/var/mail"
>  #define _PATH_MAN "/usr/share/man"
> -#define _PATH_MDCONFIG "/sbin/mdconfig"
> +#define _PATH_MDCONFIG "/bin/mdconfig"
>  #define _PATH_MEM "/dev/mem"
> -#define _PATH_MKSNAP_FFS "/sbin/mksnap_ffs"
> -#define _PATH_MOUNT "/sbin/mount"
> -#define _PATH_NEWFS "/sbin/newfs"
> +#define _PATH_MKSNAP_FFS "/bin/mksnap_ffs"
> +#define _PATH_MOUNT "/bin/mount"
> +#define _PATH_NEWFS "/bin/newfs"
>  #define _PATH_NOLOGIN "/var/run/nologin"
>  #define _PATH_RCP "/bin/rcp"
> -#define _PATH_REBOOT "/sbin/reboot"
> +#define _PATH_REBOOT "/bin/reboot"
>  #define _PATH_RLOGIN "/usr/bin/rlogin"
>  #define _PATH_RM "/bin/rm"
>  #define _PATH_RSH "/usr/bin/rsh"
> -#define _PATH_SENDMAIL "/usr/sbin/sendmail"
> +#define _PATH_SENDMAIL "/usr/bin/sendmail"
>  #define _PATH_SHELLS "/etc/shells"
>  #define _PATH_TTY "/dev/tty"
>  #define _PATH_UNIX "don't use _PATH_UNIX"
> @@ -107,9 +107,9 @@
>  #undef _PATH_DEFPATH
>  #define _PATH_DEFPATH "/rescue:/usr/bin:/bin"
>  #undef _PATH_STDPATH
> -#define _PATH_STDPATH "/rescue:/usr/bin:/bin:/usr/sbin:/sbin"
> +#define _PATH_STDPATH "/rescue:/usr/bin:/bin"
>  #undef _PATH_SYSPATH
> -#define _PATH_SYSPATH "/rescue:/sbin:/usr/sbin"
> +#define _PATH_SYSPATH "/rescue:/bin:/usr/bin"
>  #undef _PATH_BSHELL
>  #define _PATH_BSHELL "/rescue/sh"
>  #undef _PATH_CP
> Index: sbin/Makefile.inc
> ===================================================================
> --- sbin/Makefile.inc (revision 227417)
> +++ sbin/Makefile.inc (working copy)
> @@ -3,7 +3,7 @@
>  
>  .include <bsd.own.mk>
>  
> -BINDIR?= /sbin
> +BINDIR?= /bin
>  WARNS?= 6
>  
>  .if ${MK_DYNAMICROOT} == "no"
> Index: Makefile.inc1
> ===================================================================
> --- Makefile.inc1 (revision 227417)
> +++ Makefile.inc1 (working copy)
> @@ -613,6 +613,18 @@
>  .endfor
>  
>  #
> +# /sbin is now merged into /bin. The same holds for /usr/sbin and /usr/games.
> +#
> +installcheck: installcheck_sbin_merge
> +installcheck_sbin_merge:
> +.for dir in ${DESTDIR}/sbin ${DESTDIR}/usr/sbin ${DESTDIR}/usr/games
> + @if test -d ${dir} -a ! -L ${dir}; then \
> + echo "ERROR: Directory ${dir} is still present, see /usr/src/UPDATING entry 20111110."; \
> + false; \
> + fi
> +.endfor
> +
> +#
>  # Required install tools to be saved in a scratch dir for safety.
>  #
>  .if ${MK_INFO} != "no"
> Index: cddl/sbin/Makefile.inc
> ===================================================================
> --- cddl/sbin/Makefile.inc (revision 227417)
> +++ cddl/sbin/Makefile.inc (working copy)
> @@ -1,5 +1,5 @@
>  # $FreeBSD$
>  
> -BINDIR?= /sbin
> +BINDIR?= /bin
>  
>  .include "../Makefile.inc"
> Index: cddl/usr.sbin/dtrace/Makefile
> ===================================================================
> --- cddl/usr.sbin/dtrace/Makefile (revision 227417)
> +++ cddl/usr.sbin/dtrace/Makefile (working copy)
> @@ -4,7 +4,7 @@
>  
>  PROG= dtrace
>  SRCS= dtrace.c
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  WARNS?= 1
>  
> Index: cddl/usr.sbin/plockstat/Makefile
> ===================================================================
> --- cddl/usr.sbin/plockstat/Makefile (revision 227417)
> +++ cddl/usr.sbin/plockstat/Makefile (working copy)
> @@ -4,7 +4,7 @@
>  
>  PROG= plockstat
>  SRCS= plockstat.c
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  WARNS?= 1
>  
> Index: cddl/usr.sbin/lockstat/Makefile
> ===================================================================
> --- cddl/usr.sbin/lockstat/Makefile (revision 227417)
> +++ cddl/usr.sbin/lockstat/Makefile (working copy)
> @@ -5,7 +5,7 @@
>  PROG= lockstat
>  NO_MAN=
>  SRCS= lockstat.c sym.c
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  WARNS?= 1
>  
> Index: cddl/usr.sbin/Makefile.inc
> ===================================================================
> --- cddl/usr.sbin/Makefile.inc (revision 227417)
> +++ cddl/usr.sbin/Makefile.inc (working copy)
> @@ -1,5 +1,5 @@
>  # $FreeBSD$
>  
> -BINDIR?= /usr/sbin
> +BINDIR?= /usr/bin
>  
>  .include "../Makefile.inc"
> Index: ObsoleteFiles.inc
> ===================================================================
> --- ObsoleteFiles.inc (revision 227417)
> +++ ObsoleteFiles.inc (working copy)
> @@ -2164,8 +2164,6 @@
>  OLD_FILES+=usr/libexec/named-xfer
>  OLD_FILES+=usr/sbin/named.restart
>  OLD_FILES+=usr/sbin/ndc
> -OLD_FILES+=usr/sbin/nslookup
> -OLD_FILES+=usr/sbin/nsupdate
>  OLD_FILES+=usr/share/doc/bind/html/acl.html
>  OLD_FILES+=usr/share/doc/bind/html/address_list.html
>  OLD_FILES+=usr/share/doc/bind/html/comments.html
> @@ -2528,7 +2526,6 @@
>  # 200212XX
>  OLD_FILES+=usr/sbin/kenv
>  OLD_FILES+=usr/bin/kenv
> -OLD_FILES+=usr/sbin/elf2aout
>  # 200210XX
>  OLD_FILES+=usr/include/libusbhid.h
>  OLD_FILES+=usr/share/man/man3/All_FreeBSD.3.gz
> Index: UPDATING
> ===================================================================
> --- UPDATING (revision 227417)
> +++ UPDATING (working copy)
> @@ -22,6 +22,24 @@
>   machines to maximize performance.  (To disable malloc debugging, run
>   ln -s aj /etc/malloc.conf.)
>  
> +20111110:
> + The /sbin, /usr/sbin and /usr/games directories have been merged
> + into /bin and /usr/bin. For compatibility, the old directories
> + have been replaced by symbolic links pointing to `bin'. To
> + prevent people from possibly breaking their system
> + automatically, you must perform the merge manually before
> + `make installworld'. This can be done as follows:
> +
> + chflags noschg /sbin/* /usr/sbin/* /usr/games/*
> + mv /sbin/* /bin
> + mv /usr/sbin/* /usr/games/* /usr/bin
> + rmdir /sbin /usr/sbin /usr/games
> +
> + After running these commands, you can safely run `make
> + installworld' to continue your upgrade. Do not reboot your
> + system in the mean time, as FreeBSD's boot procedure depends on
> + the existence of /sbin and /usr/sbin.
> +
>  20111108:
>   The option VFS_ALLOW_NONMPSAFE option has been added in order to
>   explicitely support non-MPSAFE filesystems.
> Index: libexec/bootpd/tools/Makefile.inc
> ===================================================================
> --- libexec/bootpd/tools/Makefile.inc (revision 227417)
> +++ libexec/bootpd/tools/Makefile.inc (working copy)
> @@ -1,6 +1,6 @@
>  # Makefile.inc
>  # $FreeBSD$
>  
> -BINDIR= /usr/sbin
> +BINDIR= /usr/bin
>  
>  WARNS?= 1
> Index: etc/mtree/BSD.usr.dist
> ===================================================================
> --- etc/mtree/BSD.usr.dist (revision 227417)
> +++ etc/mtree/BSD.usr.dist (working copy)
> @@ -7,8 +7,7 @@
>  .
>      bin
>      ..
> -    games
> -    ..
> +    games           type=link link=bin
>      include
>      ..
>      lib
> @@ -55,8 +54,7 @@
>      ..
>      obj             nochange
>      ..
> -    sbin
> -    ..
> +    sbin            type=link link=bin
>      share
>          calendar
>              de_DE.ISO8859-1
> Index: etc/mtree/BSD.root.dist
> ===================================================================
> --- etc/mtree/BSD.root.dist (revision 227417)
> +++ etc/mtree/BSD.root.dist (working copy)
> @@ -85,8 +85,7 @@
>      ..
>      root
>      ..
> -    sbin
> -    ..
> +    sbin            type=link link=bin
>      tmp             mode=01777
>      ..
>      usr
> Index: etc/login.conf
> ===================================================================
> --- etc/login.conf (revision 227417)
> +++ etc/login.conf (working copy)
> @@ -27,7 +27,7 @@
>   :copyright=/etc/COPYRIGHT:\
>   :welcome=/etc/motd:\
>   :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
> - :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin ~/bin:\
> + :path=/bin /usr/bin /usr/local/sbin /usr/local/bin ~/bin:\
>   :nologin=/var/run/nologin:\
>   :cputime=unlimited:\
>   :datasize=unlimited:\
> @@ -163,7 +163,7 @@
>  # :ignoretime:\
>  # :requirehome@:\
>  # :accounted@:\
> -# :path=~/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin:\
> +# :path=~/bin /bin /usr/bin /usr/local/bin /usr/local/sbin:\
>  # :umask=022:\
>  # :tc=standard:
>  #
> @@ -172,7 +172,7 @@
>  ## root - fallback for root logins
>  ##
>  #root:\
> -# :path=~/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin:\
> +# :path=~/bin /bin /usr/bin /usr/local/bin /usr/local/sbin:\
>  # :cputime=infinity:\
>  # :datasize=infinity:\
>  # :stacksize=infinity:\
> @@ -214,7 +214,7 @@
>  ## Settings used by news subsystem
>  ##
>  #news:\
> -# :path=/usr/local/news/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin:\
> +# :path=/usr/local/news/bin /bin /usr/bin /usr/local/bin /usr/local/sbin:\
>  # :cputime=infinity:\
>  # :filesize=128M:\
>  # :datasize-cur=64M:\

> /sbin, /usr/sbin and /usr/games separate:
>  PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/ed/bin
>   => /sbin
>    263.38 real 80.16 user 185.91 sys
>   => /bin
>    263.73 real 79.81 user 186.33 sys
>   => /usr/sbin
>    264.08 real 76.82 user 189.69 sys
>   => /usr/bin
>    264.44 real 78.04 user 188.80 sys
>   => /usr/games
>    265.21 real 78.92 user 188.72 sys
>   => /usr/local/sbin
>    266.19 real 78.54 user 190.04 sys
>   => /usr/local/bin
>    266.58 real 78.53 user 190.31 sys
>   => /home/ed/bin
>    267.84 real 78.21 user 191.91 sys
>  PATH=/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/ed/bin
>   => /bin
>    262.75 real 79.18 user 185.91 sys
>   => /usr/bin
>    263.49 real 76.18 user 189.86 sys
>   => /usr/local/sbin
>    264.51 real 77.81 user 189.07 sys
>   => /usr/local/bin
>    265.14 real 77.97 user 189.53 sys
>   => /home/ed/bin
>    266.14 real 76.18 user 192.33 sys
> /sbin, /usr/sbin and /usr/games merged:
>  PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/ed/bin
>   => /sbin
>    264.12 real 78.53 user 188.00 sys
>   => /bin
>    263.96 real 78.46 user 187.92 sys
>   => /usr/sbin
>    265.21 real 77.12 user 190.47 sys
>   => /usr/bin
>    265.44 real 77.59 user 190.21 sys
>   => /usr/games
>    265.55 real 78.52 user 189.42 sys
>   => /usr/local/sbin
>    267.28 real 78.21 user 191.37 sys
>   => /usr/local/bin
>    267.48 real 77.20 user 192.66 sys
>   => /home/ed/bin
>    268.73 real 77.79 user 193.30 sys
>  PATH=/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/ed/bin
>   => /bin
>    263.59 real 76.95 user 189.03 sys
>   => /usr/bin
>    264.37 real 76.95 user 189.84 sys
>   => /usr/local/sbin
>    265.15 real 78.53 user 189.03 sys
>   => /usr/local/bin
>    265.75 real 77.10 user 190.98 sys
>   => /home/ed/bin
>    266.89 real 77.06 user 192.13 sys



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
123