Minor size optimization
The attached diff shaves four bytes from every syscall wrapper (e.g., __sys_write, etc.) In looking carefully at library sizes, I became curious why a simple system call required 20 bytes; turns out a lot of that was alignment padding. Tim Kientzle Index: lib/libc/i386/SYS.h === RCS file: /mnt/cvs/src/lib/libc/i386/SYS.h,v retrieving revision 1.24 diff -c -r1.24 SYS.h *** lib/libc/i386/SYS.h 17 Sep 2002 01:48:51 - 1.24 --- lib/libc/i386/SYS.h 8 Nov 2002 06:15:21 - *** *** 48,54 .set CNAME(__CONCAT(_,x)),CNAME(__CONCAT(__sys_,x)); \ mov __CONCAT($SYS_,x),%eax; KERNCALL; jb 2b ! #define RSYSCALL(x) SYSCALL(x); ret #define PSEUDO(x) ENTRY(__CONCAT(__sys_,x)); \ .weak CNAME(__CONCAT(_,x)); \ --- 48,63 .set CNAME(__CONCAT(_,x)),CNAME(__CONCAT(__sys_,x)); \ mov __CONCAT($SYS_,x),%eax; KERNCALL; jb 2b ! /* Version 1: More compact source */ ! /* #defineRSYSCALL(x) SYSCALL(x); ret */ ! /* Version 2: More compact object code (fewer alignment requirements) */ ! #define RSYSCALL(x) ENTRY(__CONCAT(__sys_,x)); \ ! .weak CNAME(x); \ ! .set CNAME(x),CNAME(__CONCAT(__sys_,x));\ ! .weak CNAME(__CONCAT(_,x)); \ ! .set CNAME(__CONCAT(_,x)),CNAME(__CONCAT(__sys_,x)); \ ! mov __CONCAT($SYS_,x),%eax; KERNCALL; jb 2f; ret; \ ! 2: PIC_PROLOGUE; jmp PIC_PLT(HIDENAME(cerror)) #define PSEUDO(x) ENTRY(__CONCAT(__sys_,x)); \ .weak CNAME(__CONCAT(_,x)); \
Re: libc size
Andre Albsmeier wrote: I would like to compile the whole base system (maybe even the ports) without the whole setlocale stuff. Do you have any ideas of how to do this easily? Replace setlocale() in lib/libc/locale with a stub. That should do it. Of course, this doesn't really save you that much. Most binaries are dynamically linked, so this saves nothing on disk space for those executables. It's a couple of K for those statically-linked executables that use it, but there aren't that many of them. If you're worried about disk space for the locale data itself, you can simply delete any locales you don't use from /usr/share/locale It comes up in the context of 'cat' only because it more than doubles the size of an otherwise very small executable for a single option that is not standard and (probably) not ever used. This is a pretty unusual situation. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
Miguel Mendez wrote:
Tim Kientzle [EMAIL PROTECTED] wrote:
1) Fragility. Could a naive sysadmin (or a dying
disk) break /[s]bin?
What if the ldconfig hints files were hosed?
Is ld-elf.so truly bulletproof?
Agreed, and, fortunately, that was taken into account with the
introduction of the /rescue dir:
christine: {48} du -h /rescue
2.4M/rescue
Oh. So the real size of NetBSD's /bin and /sbin includes
another 2.4M for /rescue. That makes it less
impressive. I don't find the duplication appealing, either.
(Why not just put the /rescue versions directly
into /bin and /sbin? That would be smaller still,
wouldn't it?)
2) Security. Can LD_LIBRARY_PATH (or other mechanisms)
be used to deliberately subvert any of these programs?
(especially the handful of suid/sgid programs here)
Several people have pointed out that FreeBSD has
certain protections against LD_LIBRARY_PATH exploits,
but there are still real questions here. (Kernel
races, possibly?) Privilege elevation is an
interesting idea, but tricky to audit.
the results from ls -l /bin on your NetBSD system
christine: {66} ls -l /bin
-r-xr-xr-x 1 root wheel8480 Oct 29 22:59 cat
-r-xr-xr-x 1 root wheel4892 Oct 29 23:00 echo
-r-xr-xr-x 1 root wheel5568 Oct 29 23:01 rmdir
-r-xr-xr-x 1 root wheel5892 Oct 29 23:02 sleep
-r-xr-xr-x 1 root wheel4652 Oct 29 23:02 sync
[[ others omitted ]]
sigh I've been looking at some of the FreeBSD standard utils,
and with a very little bit of work got this:
-rwxr-xr-x 1 tim tim 9552 Nov 4 11:10 cat
-rwxr-xr-x 1 tim tim 2776 Nov 4 11:10 echo
-rwxr-xr-x 1 tim tim 3288 Nov 1 13:48 rmdir
-rwxr-xr-x 1 tim tim 2904 Nov 4 11:10 sleep
-rwxr-xr-x 1 tim tim 2424 Nov 4 11:10 sync
All statically linked, all portable C, with identical
functionality to the originals. If statically-linked
versions can be 1/2 the size of the dynamic versions,
then I _really_ don't see the advantage of dynamic linking.
Perhaps some more careful programming is all that's needed? ;-)
(Admittedly, a space-conscious overhaul of sh, csh, or ed
is not entirely trivial; but most of /bin and /sbin is pretty simple
to prune down.)
rcNG has been in work for a long time. Is it worth it? Absolutely,
try it once and you'll wonder how you could live with the old system, or
even with the sysV symlink crazyness.
As it happens, I've been looking closely at RCng
just recently. Though I really like the core design, I do
have some quibbles with the implementation. It
is usable today, and does address the worst problems
of SysV-style init. Still needs some work, though. ;-)
Tim Kientzle
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libc size
I agree with David Schultz that dynamically linking /bin and /sbin is playing with fire. I, too, have had ugly experiences on systems that did this: When /usr won't mount, it is not pleasant to be stuck with no tools. (Consider a network environment where /usr is NFS-mounted as an extreme example.) As for the disk space concerns, I spent a couple of hours with some of the smaller utilities. Identical functionality to the originals, still statically linked. Compare with 'ls -l /bin' on your system: * echo: 3k * sleep: 3k * sync: 3k * cat: 40k with setlocale, 12k without (cat uses setlocale for non-standard -v option) Total savings: over 150k just from these four. This is under 4.x, though; last I checked, -CURRENT still had some ugly bloat in crt. (crt requires atexit, which requires malloc, ugh. Maybe this has been fixed?) Easily-commitable details on request. As for the resolver issue, maybe there's another way to separate the resolver? For example, a simple command-line resolver utility (something like a stripped-down 'dig') could be invoked. That would leave one utility with the resolver libs statically-linked, and remove it from many other places. There's an obvious performance hit, but resolving is a fairly high-overhead operation in any case. Alternatively, some sort of simple resolver daemon could be implemented. The BIND folks are already moving in this direction because of IP6 resolver bloat, I understand. Either approach would shed resolver bloat from a lot of places without the headaches of dynamic linking. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
Wesley Morgan [EMAIL PROTECTED] wrote:
... create a /lib ... that I would *never ever* want to see.
Miguel Mendez wrote:
Why? I'd love to hear some real reasons for this.
I can think of three concerns:
1) Fragility. Could a naive sysadmin (or a dying
disk) break /[s]bin?
What if the ldconfig hints files were hosed?
Is ld-elf.so truly bulletproof?
2) Security. Can LD_LIBRARY_PATH (or other mechanisms)
be used to deliberately subvert any of these programs?
(especially the handful of suid/sgid programs here)
3) Upgrade breakage. Will this make upgrades more fragile?
A broken or incomplete upgrade could damage ld-elf.so
or introduce version skew between /bin and libc.so.
(Yes, people do rebuild libc without rebuilding world.)
I am certain these concerns could be addressed,
and a dynamic /bin could be made workable, but
it would require a lot of care.
christine: {16} uname -srnm
NetBSD christine.energyhq.tk 1.6J i386
christine: {17} du -h /bin /sbin /lib
999K/bin
1.7M/sbin
2.0M/lib
That's impressive; FreeBSD's /bin is over 7M by
itself right now. I would be curious to see
the results from ls -l /bin on your NetBSD system
as well.
... a knob in /etc/mk.conf to get the old behaviour,
how about something like that?
Knobs are dangerous because you have to test
all of the settings.
Tim Kientzle
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RCng Awkwardness
I find the standard arguments used by RCng quite awkward. In particular, especially for people who have worked with SysV-style init scripts, it's rather surprising that /etc/rc.d/nfsd stop does not actually stop the nfsd process. Likewise, 'start' doesn't actually start the specified system. I would find it vastly more intuitive if the current arguments were named differently: current 'start' - new 'boot' current 'stop' - new 'shutdown' current 'forcestart' - new 'start' current 'forcestop' - new 'stop' This better reflects the actual usage: the current 'start' and 'stop' are really intended to be used by RC at system boot and shutdown time. 'forcestart' and 'forcestop' are really for manually starting/stopping services. For that matter, I don't really understand why 'stop' and 'forcestop' are separate anyway; if I type 'stop', I want it to stop, even if rc.conf says it shouldn't be running. I could provide diffs to change this, but won't bother if everyone else thinks the existing system is perfect and unalterable. ;-) Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RCng Awkwardness
Gordon Tetlow wrote: On Wed, Oct 30, 2002 at 11:50:45AM -0800, Tim Kientzle wrote: I find the standard arguments used by RCng quite awkward. In particular, ... /etc/rc.d/nfsd stop does not actually stop the nfsd process. ... ... I've found this behavior to be quite annoying. I'll see if I can put something together. If you want to help me out and put together the patches, I'd be more than happy to commit them. I have something partly sketched out, but it still needs some work. I can send you something in the next couple of days to look at. I see two awkward issues: * Is it necessary to distinguish 'stop' (unconditional stop) from 'shutdown' (stop only if enabled)?? Seems that at system shutdown you want everything to be taken down, regardless of whether it was brought up at boot or brought up manually post-boot. The unconditional 'stop' seems to be all that's needed. * Local rc scripts (in /usr/local/etc/rc.d) will still get run with a 'start' argument, while system scripts in /etc/rc.d will get a 'boot' argument. That's a bit awkward, but still reasonably consistent: 'start' is still an unconditional operation. I don't see any way around this without breaking existing systems after upgrade. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
Nate Lawson wrote: Here is a link to the size of various components of libc, ... Terry Lambert wrote: Move the resolver code out to ibresolv.so, ... Peter Wemm: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. Peter, Could you elaborate? I'm not sure I follow you. How would dynamically linking /bin and /sbin make this work right? Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
M. Warner Losh wrote: Tim Kientzle [EMAIL PROTECTED] writes: : ... 'installkernel' is not filling it's contract: it is : not ensuring that the next boot uses the new kernel. Are you sure you need new bootblocks? I've not had issues and am pretty careless about when I do installworld vs installkernel. You need them for the 4.x - 5.0 upgrade, but I didn't think you've needed new ones for a long time now. In case you've forgotten, in another month or two, thousands of people are going to be upgrading from 4.x - 5.0. Those are going to be people who don't regularly read -current or even -stable. The upgrade process right now is getting pretty ugly and needs to be cleaned up some before release. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Thus spake Lucky Green [EMAIL PROTECTED]: ... remove ssh1 fallback from the default ... David Schultz [EMAIL PROTECTED] wrote: Removing SSH 1 ... is going to break compatibility ... Tim Kientzle [EMAIL PROTECTED]: POLA: before breaking compatibility, warn people. ... Warning: switching to less-secure SSH1 protocol David Schultz wrote: I think you're missing the point. Warnings are fine, but there is little good reason to disable SSH1 entirely. _I_ was actually arguing against disabling SSH1. I'm on your side. If one end of the connection is forced to fall back to SSH1, it's almost certainly because the user at the other end _doesn't_have_any_other_option_. I don't really agree with this point. SSH2 and OpenSSH compile most everywhere now. I would argue that if one end is forced to fall back, it's because the admins of that system either don't know about SSH1's problems or don't believe those problems merit upgrades. I know SSH1 is insecure, and therefore I don't use it. Unfortunately, not everyone is so knowledgable. A brief warning would help spread the news and (hopefully) help accelerate the transition to SSH2. ... you'd better have a better reason to do it than ``it lets people do things that are insecure.'' So do rsh, telnet, hosts.equiv, vipw, et al. Yes, although telnet and rsh are both disabled in default FreeBSD installations in 4.7 at least and probably earlier. So far, I've not heard a lot of complaints. (But there have been several years now of pounding the 'telnet is evil' mantra into people's heads.) Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: you need to install a new kernel before an installworld.
Peter Wemm wrote: 'make installworld' without ... a new kernel would be rather messy. ... a reminder of the sequence is probably in order: buildworld buildkernel installkernel reboot installworld reboot This _does_not_work_ because 'installkernel' does not update the bootblocks. It should. Otherwise, 'installkernel' is not filling it's contract: it is not ensuring that the next boot uses the new kernel. An alternative: have installkernel link the new kernel file back to the old location, at least until 5.1. That way, either old or new boot blocks would boot the new kernel. (This may be the better approach all around; it leaves the downgrade option available for a little bit longer.) Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
One possible solution to the sort problem: * Continue to accept the old syntax for now, but add a warning message, something like: Warning: sort +N is deprecated, use -k instead. * After a year, drop support for the old syntax. After staring at warning messages for a year, few people will be able to claim ignorance. The messages will serve both to advertise the change and to flag those scripts that rely on the old syntax. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Another aic7xxx kernel build failure...
Another issue with 'aicasm': It breaks the following: * Vanilla install of 4.6-RELEASE (from CD-ROM) * Pull 5.0-CURRENT sources (as of 2 Sept 2002) * 'make buildworld' * 'make kernel' The kernel compile breaks when it tries to run aicasm, with a message about 'libc.so.5' not being available. It looks like aicasm is being compiled (and dynamically linked) against the new world (5.0-CURRENT), but then gets run in the currently-installed world (4.6-RELEASE). I worked around by manually compiling aicasm in the installed world (cd /aicasm make aicasm) and copying it into the /usr/obj tree. Then 'make kernel' was able to succeed. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
