headers
Gordon Tetlow | 1 Jun 2003 01:16
Favicon

Re: Moving some items out of src/sbin to src/usr.sbin

On Sat, May 31, 2003 at 03:27:47PM -0700, David O'Brien wrote:
> On Sun, Jun 01, 2003 at 08:09:57AM +1000, Peter Jeremy wrote:
> > On Sat, May 31, 2003 at 01:22:21PM -0700, David O'Brien wrote:
> > >On Sat, May 31, 2003 at 12:38:49PM -0700, Gordon Tetlow wrote:
> > >> To cut down on the size of a dynamically-linked root, I'd like to
> > >> repo-copy the following utilities from src/sbin to src/usr.sbin:
> > >> 
> > >> mount_portalfs
> > >> mount_nwfs
> > >> mount_smbfs
> > >> natd
> > >> ipnat
> > >> 
> > >> Does anyone have any objections?
> > >
> > >yes to natd.
> > 
> > David, would you like to go into a bit more detail please.
> ...
> > NAT is normally used at boundaries between different privilege zones
> > (though this isn't its only use) and it would seem unusual to mount
> > /usr from a different privilege zone to the local system.  Normally,
> > natd is started before ipfw rules are loaded, but I don't believe
> > there is a requirement for a process to be bound to a divert socket
> > before diversion rules are added.
> 
> Not really.  Just to say that as a user of natd and one that knows how
> fragile ipfw & natd are to passing packets I don't want to disturb things.
> I want to see some people (other than me) experiment with this the natd
> issue before it is moved.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Terry Lambert | 1 Jun 2003 08:33
Picon

Re: Moving some items out of src/sbin to src/usr.sbin

Gordon Tetlow wrote:
> On Sat, May 31, 2003 at 12:50:46PM -0700, Terry Lambert wrote:
> > I would actually be tempted to go farther, and to adopt the SVR4
> > layout for these types of programs, and the stub programs that
> > call them, and put them under /libexec; that probably would not
> > fly to well, even though it would mean you could drop in new
> > file systems, and the tools would "just know" about them.
> 
> They already do. mount -t foo will try execing /sbin/mount_foo
> and then /usr/sbin/mount_foo. You'd know that if you read the
> source.

This is disingenuous.  By saying this, you imply that the mount
code is able to access things that, it'd be there in the default
case, of programs with the install disks.

As an example, using your approach, it would be impossible to
install from an NTFS partition... which is to say it'd be
impossible to install from Winwodws XP.

-- Terry
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Bruce Evans | 1 Jun 2003 14:25
Picon

Re: Moving some items out of src/sbin to src/usr.sbin

On Sat, 31 May 2003, Gordon Tetlow wrote:

> On Sat, May 31, 2003 at 03:28:22PM -0700, Julian Elischer wrote:

> > > On Sat, May 31, 2003 at 12:38:49PM -0700, Gordon Tetlow wrote:
> > > > To cut down on the size of a dynamically-linked root, I'd like to
> > > > repo-copy the following utilities from src/sbin to src/usr.sbin:
> > > >
> > > > mount_portalfs
> > > > mount_nwfs
> > > > mount_smbfs
> > > > natd
> > > > ipnat
> > > >
> > > > Does anyone have any objections?
> > it would make it hard to mount an smbfs /usr right?
> >
> > I think it goes against POLA to mofe mount subtypes away from where they
> > are..
>
> mount_smbfs is dynamically linked currently. You can't use it to mount
> /usr even if you wanted to. No POLA will be broken by moving it. And
> if you are using nwfs or portalfs for /usr, may $DEITY have pity on your
> soul.

There is little point in moving the utilities for the dynamically linked
case, since they are small in that case.  Just don't put their libraries
in the root partition, so that they work like mount_smbfs does now (not,
if /usr is not mounted).
(Continue reading)

Permalink | Reply | 2 comments |
headers
R. Imura | 1 Jun 2003 20:00

Re: Moving some items out of src/sbin to src/usr.sbin

Hi, Bruce,

On Sun, Jun 01, 2003 at 10:25:26PM +1000, Bruce Evans wrote:
> mount_smbfs isn't actually dynamically linked currently:
> 
> %%%
> $ file /sbin/mount_smbfs
> /sbin/mount_smbfs: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 5.0,
statically linked, stripped
> %%%
> 
> The world was built with NOSHARED=yes.
> 
> This seems to be a bug in mount_smbfs/Makefile:
> 
> %%%
> # Needs to be dynamically linked for optional dlopen() access to
> # userland libiconv (see the -E option).
> #
> NOSHARED?=	NO
> %%%
> 
> If it really needs to be dynamically linked, then NOSHARED should
> be set unconditionally.

When statically linked, mount_smbfs is limited to no character conversion
based on libiconv.so, because dlopen() returns "Service unavailable".
Since smbfs works fine w/o code conversion, if someone wants, he can
make it statically linked. I think European need dynamically linked
for their character code conversion purpose.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ruslan Ermilov | 2 Jun 2003 00:30
Picon
Favicon

Re: Moving some items out of src/sbin to src/usr.sbin

On Sat, May 31, 2003 at 12:38:49PM -0700, Gordon Tetlow wrote:
> To cut down on the size of a dynamically-linked root, I'd like to
> repo-copy the following utilities from src/sbin to src/usr.sbin:
> 
> mount_portalfs
> mount_nwfs
> mount_smbfs
> natd
> ipnat
> 
> Does anyone have any objections?
> 
natd(8) is there for a good reason; it's usually started
synchronously with ipfw(8), at which time /usr may not
yet be available.

Cheers,
--

-- 
Ruslan Ermilov		Sysadmin and DBA,
ru <at> sunbay.com		Sunbay Software AG,
ru <at> FreeBSD.org		FreeBSD committer.
Permalink | Reply | 0 comments |
headers
Bruce Evans | 2 Jun 2003 00:52
Picon

Re: Moving some items out of src/sbin to src/usr.sbin

On Mon, 2 Jun 2003, R. Imura wrote:

> On Sun, Jun 01, 2003 at 10:25:26PM +1000, Bruce Evans wrote:
> > mount_smbfs isn't actually dynamically linked currently:
> >
> > %%%
> > $ file /sbin/mount_smbfs
> > /sbin/mount_smbfs: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 5.0,
statically linked, stripped
> > %%%
> >
> > The world was built with NOSHARED=yes.
> >
> > This seems to be a bug in mount_smbfs/Makefile:
> >
> > %%%
> > # Needs to be dynamically linked for optional dlopen() access to
> > # userland libiconv (see the -E option).
> > #
> > NOSHARED?=	NO
> > %%%
> >
> > If it really needs to be dynamically linked, then NOSHARED should
> > be set unconditionally.
>
> When statically linked, mount_smbfs is limited to no character conversion
> based on libiconv.so, because dlopen() returns "Service unavailable".
> Since smbfs works fine w/o code conversion, if someone wants, he can
> make it statically linked. I think European need dynamically linked
> for their character code conversion purpose.
(Continue reading)

Permalink | Reply | 0 comments |
headers
alunos-admin | 2 Jun 2003 01:58
Picon

Your message to Alunos awaits moderator approval

Your mail to 'Alunos' with the subject

    Re: 45443-343556

Is being held until the list moderator can review it for approval.

The reason it is being held:

    Post to moderated list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Alexey Neyman | 2 Jun 2003 10:21
Picon
Favicon

Re: cvs commit: src/sys/i386/i386 atomic.c autoconf.c bios.c busdma_machdep.c critical.c db_disasm.c db_interface.c db_trace.c dump_machdep.c elan-mmcr.c elf_machdep.c genassym.c i386-gdbstub.c i686_mem.c identcpu.c in_cksum.c initcpu.c k6_mem.c legacy.c ...

Hi, there!

On Monday 02 June 2003 10:43, David E. O'Brien wrote:
DE>   Modified files:
DE>     sys/i386/i386        atomic.c autoconf.c bios.c 
DE>                          busdma_machdep.c critical.c db_disasm.c 
DE>                          db_interface.c db_trace.c dump_machdep.c 
DE>                          elan-mmcr.c elf_machdep.c genassym.c 
DE>                          i386-gdbstub.c i686_mem.c identcpu.c 
DE>                          in_cksum.c initcpu.c k6_mem.c legacy.c 
DE>                          machdep.c math_emulate.c mem.c mp_clock.c 
DE>                          mp_machdep.c mpapic.c nexus.c perfmon.c 
DE>                          pmap.c sys_machdep.c trap.c tsc.c vm86.c 
DE>                          vm_machdep.c 
DE>   Log:
DE>   Use __FBSDID().

BTW, I have a patch that strips the version information (more precisely,
.comment section, that contains $FreeBSD$ strings and a handful of
compiler versions "GCC: (GNU) 3.2.2 [FreeBSD] 20030205 (release)") into
a separate file and installs it under a separate name (${KMOD}.version
or kernel.version).

Even now, .comment section in GENERIC is somewhat about 30K (this gives
about 2.5K in the compressed kernel), but it will obviously grow as 
more __FBSDID()s are added.

PS. The patch is against ~1 week old sources, however, it should apply 
ok.
(Continue reading)

Permalink | Reply | 2 comments |
headers
David O'Brien | 2 Jun 2003 17:02

Re: cvs commit: src/sys/i386/i386 atomic.c autoconf.c bios.c busdma_machdep.c critical.c db_disasm.c db_interface.c db_trace.c dump_machdep.c elan-mmcr.c elf_machdep.c genassym.c i386-gdbstub.c i686_mem.c identcpu.c in_cksum.c initcpu.c k6_mem.c legacy.c ...

On Mon, Jun 02, 2003 at 12:21:47PM +0400, Alexey Neyman wrote:
> Hi, there!
> 
> On Monday 02 June 2003 10:43, David E. O'Brien wrote:
> DE>   Modified files:
> DE>     sys/i386/i386        atomic.c autoconf.c bios.c 
> DE>                          busdma_machdep.c critical.c db_disasm.c 
> DE>                          db_interface.c db_trace.c dump_machdep.c 
> DE>                          elan-mmcr.c elf_machdep.c genassym.c 
> DE>                          i386-gdbstub.c i686_mem.c identcpu.c 
> DE>                          in_cksum.c initcpu.c k6_mem.c legacy.c 
> DE>                          machdep.c math_emulate.c mem.c mp_clock.c 
> DE>                          mp_machdep.c mpapic.c nexus.c perfmon.c 
> DE>                          pmap.c sys_machdep.c trap.c tsc.c vm86.c 
> DE>                          vm_machdep.c 
> DE>   Log:
> DE>   Use __FBSDID().
> 
> BTW, I have a patch that strips the version information (more precisely,
> .comment section, that contains $FreeBSD$ strings and a handful of
> compiler versions "GCC: (GNU) 3.2.2 [FreeBSD] 20030205 (release)") into
> a separate file and installs it under a separate name (${KMOD}.version
> or kernel.version).

What's the problem with a large amount .comment section bits?  They
should not be loaded into memory when an ELF file is loaded.  The only
place it causes trouble is on the installation floppies when the size of
the file on disk is an issue -- but we strip out the .comment section
when building the floppy images.
_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexey Neyman | 2 Jun 2003 18:40
Picon
Favicon

Re: cvs commit: src/sys/i386/i386 atomic.c autoconf.c bios.c busdma_machdep.c critical.c db_disasm.c db_interface.c db_trace.c dump_machdep.c elan-mmcr.c elf_machdep.c genassym.c i386-gdbstub.c i686_mem.c identcpu.c in_cksum.c initcpu.c k6_mem.c legacy.c ...

hi, there!

On Monday 02 June 2003 19:02, David O'Brien wrote:
DO>> BTW, I have a patch that strips the version information (more 
precisely,
DO>> .comment section, that contains $FreeBSD$ strings and a handful of
DO>> compiler versions "GCC: (GNU) 3.2.2 [FreeBSD] 20030205 (release)") 
into
DO>> a separate file and installs it under a separate name 
(${KMOD}.version
DO>> or kernel.version).
DO> 
DO> What's the problem with a large amount .comment section bits?  They
DO> should not be loaded into memory when an ELF file is loaded.  The 
only
DO> place it causes trouble is on the installation floppies when the 
size of
DO> the file on disk is an issue -- but we strip out the .comment 
section
DO> when building the floppy images.

Well, sorry for the noise. I just checked that 5.0-RELEASE floppies
contain the .comment section in the kernel. However, 5.1-BETA2 do not,
that is, such stripping was introduced somewhere in between... This,
of course, renders this patch useless.

Regards,
Alexey.

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane