Re: Creation of the NO_SSP build knob
Dag-Erling,
On Thu, Sep 04, 2008 at 09:26:28PM +0200, Dag-Erling Smørgrav wrote:
Jeremie Le Hen [EMAIL PROTECTED] writes:
If SSP belongs to this list, then NO_SSP is an alias for WITHOUT_SSP.
But it will still not be possible to use WITH_SSP in src.conf or
command-line.
[...]
Shouldn't we have a knob that overrides whatever the user says, only for
internal use in the source tree? That was my original intent when
asking if I could add NO_SSP.
That's *exactly* what NO_* does. Just add SSP to that list and replace
WITHOUT_SSP with NO_SSP wherever it occurs in Makefiles in the tree.
I've just tested it with NO_SSP and I can confirm it doesn't work
despite the explicit comment above stating otherwise. By the way, the
code is nearly identical between the supported options and the compat
ones, I don't see how it could override the user settings:
186 #
187 # Supported NO_* options (if defined, MK_* will be forced to no,
188 # regardless of user's setting).
189 #
190 .for var in \
191 INSTALLLIB \
192 MAN \
193 PROFILE \
194 SSP
195 .if defined(NO_${var})
196 WITHOUT_${var}=
197 .endif
198 .endfor
199
200 #
201 # Compat NO_* options (same as above, except their use is deprecated).
202 #
203 .if !defined(BURN_BRIDGES)
204 .for var in \
205 ACPI \
[...]
267 WPA_SUPPLICANT_EAPOL
268 .if defined(NO_${var})
269 #.warning NO_${var} is deprecated in favour of WITHOUT_${var}=
270 WITHOUT_${var}=
271 .endif
272 .endfor
273 .endif # !defined(BURN_BRIDGES)
The attached patch implements a behaviour that seems more correct
to me WRT the intent. What do you think of it?
Thanks!
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
Index: bsd.own.mk
===
RCS file: /mnt/octobre/space/freebsd-cvs/src/share/mk/bsd.own.mk,v
retrieving revision 1.77
diff -u -r1.77 bsd.own.mk
--- bsd.own.mk 16 Jun 2008 07:23:12 - 1.77
+++ bsd.own.mk 5 Sep 2008 06:56:17 -
@@ -182,19 +182,6 @@
#
#
-# Supported NO_* options (if defined, MK_* will be forced to no,
-# regardless of user's setting).
-#
-.for var in \
-INSTALLLIB \
-MAN \
-PROFILE
-.if defined(NO_${var})
-WITHOUT_${var}=
-.endif
-.endfor
-
-#
# Compat NO_* options (same as above, except their use is deprecated).
#
.if !defined(BURN_BRIDGES)
@@ -393,6 +380,19 @@
.endfor
#
+# Supported NO_* options (if defined, MK_* will be forced to no,
+# regardless of user's setting).
+#
+.for var in \
+INSTALLLIB \
+MAN \
+PROFILE
+.if defined(NO_${var})
+MK_${var}= no
+.endif
+.endfor
+
+#
# Force some options off if their dependencies are off.
# Order is somewhat important.
#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
WITHOUT_CXX but with libstdc++
Hello, I have some netbooted servers, which work off an NFS (master) server. Everything is built and installed on the master, so the netbooted images contain only what's really needed, so for example gcc is ripped out by WITHOUT_CPP=yes and WITHOUT_CXX=yes in the installworld phase. Unfortunately WITHOUT_CXX also disables the installation (given to installworld, of course if it's not built, it can't be installed) of libstdc++, which is needed for a lot of programs. Would it be possible to build CXX, but at installworld, install only the libraries (this is needed for runtime, so header files also won't be needed)? In src/gnu/lib/Makefile there is an MK_CXX test. With an OR MK_LIBCXX check (and defining WITH_LIBCXX as no by default) something similar could be done, with the limitation that at build time WITHOUT_CXX shouldn't be set and at install time, WITHOUT_CXX and WITH_LIBCXX should be yes. Any ideas about that (or a cleaner solution)? Thanks, ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Extending find(1) to support -printf
I've been working on $SUBJECT for the past few hours, and have managed
to implement a very crude subset of GNU find's features:
http://www.gnu.org/software/findutils/manual/html_node/find_html/Format-Directives.html#Format-Directives
I've implemented %f and %p (which appear identical to GNU find), and
some escaped characters.
Things I need help with, as string parsing in C has never been my forte
(which will become quite obvious):
1) Getting %h to behave like GNU find. The GNU find code is
significantly different than ours. As it stands, %h is broken.
2) find . -printf '\' results in odd output (SHELL=/usr/local/bin/bash
on my box). Not sure why this is happening, but it's a big concern.
3) Security issues. I believe use of a large number of formatting
variables could exceed the calloc()'d buffer (of MAXPATHLEN), causing
a segfault at bare minimum. I'm not sure how to work around this.
Also, some folks on #bsdports asked why I was bothering with this in the
first place: mutt supports backticks to run shell commands inside of
a muttrc file. See Building a list of mailboxes on the fly below:
http://wiki.mutt.org/?ConfigTricks
Note the find ... -printf '%h ' method. I can accomplish (just
about) the same using `echo $HOME/Maildir/*`, but if I want to
exclude an entry, I can't use | grep -v, because mutt doesn't support
pipes within backticks. :-)
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
diff -ruN find.orig/extern.h find/extern.h
--- find.orig/extern.h 2006-05-14 13:23:00.0 -0700
+++ find/extern.h 2008-09-04 20:55:17.0 -0700
@@ -73,6 +73,7 @@
creat_fc_nouser;
creat_fc_perm;
creat_fc_print;
+creat_fc_printf;
creat_fc_regex;
creat_fc_simple;
creat_fc_size;
@@ -107,6 +108,7 @@
exec_f f_perm;
exec_f f_print;
exec_f f_print0;
+exec_f f_printf;
exec_f f_prune;
exec_f f_regex;
exec_f f_size;
diff -ruN find.orig/function.c find/function.c
--- find.orig/function.c2006-05-27 11:27:41.0 -0700
+++ find/function.c 2008-09-05 03:01:36.0 -0700
@@ -1272,6 +1272,86 @@
/* c_print0 is the same as c_print */
/*
+ * -printf functions --
+ *
+ * Always true, manipulates output based on printf()-like
+ * formatting characters.
+ */
+int
+f_printf(PLAN *plan, FTSENT *entry)
+{
+ char *scan;
+ char *outptr;
+ char *outidx;
+
+ if ((outptr = calloc(MAXPATHLEN, 1)) == NULL)
+ err(1, NULL);
+
+ outidx = outptr;
+
+ for (scan = plan-c_data; *scan; scan++) {
+ if (*scan == '%') {
+ if (scan[1] == 0) {
+ errx(1, missing format character);
+ }
+ else if (scan[1] == '%') {
+ *outidx++ = '%';
+ }
+ else if (scan[1] == 'f') {
+ strcpy(outidx, entry-fts_name);
+ outidx += entry-fts_namelen;
+ }
+ /* XXX - needs to behave like GNU find %h */
+ /*
+ else if (scan[1] == 'h') {
+ strcpy(outidx, entry-fts_path);
+ outidx += entry-fts_pathlen;
+ }
+ */
+ else if (scan[1] == 'p') {
+ strcpy(outidx, entry-fts_path);
+ outidx += entry-fts_pathlen;
+ }
+ scan++;
+ }
+ else if (*scan == '\\') {
+ if (scan[1] == '\\') {
+ *outidx++ = '\\';
+ }
+ else if (scan[1] == 'n') {
+ *outidx++ = '\n';
+ }
+ else if (scan[1] == 't') {
+ *outidx++ = '\t';
+ }
+ scan++;
+ }
+ else {
+ *outidx++ = *scan;
+ }
+ }
+
+ (void)printf(outptr);
+ free(outptr);
+ return 1;
+}
+
+PLAN *
+c_printf(OPTION *option, char ***argvp)
+{
+ char *argstring;
+ PLAN *new;
+
+ argstring = nextarg(option, argvp);
+ ftsoptions = ~FTS_NOSTAT;
+ isoutput = 1;
+
+ new = palloc(option);
+ new-c_data = argstring;
+ return new;
+}
+
+/*
* -prune functions --
*
* Prune a portion of the hierarchy.
diff -ruN find.orig/option.c find/option.c
--- find.orig/option.c 2006-04-05 16:06:11.0 -0700
Re: upgrade GDB-6.1.1 on the base System
On 20080904 00:28:40, Manolo Valdes wrote: Hi Hackers reading a thread from this very list i solve my problem trying to debug user- land programs. the problem was gdb-6.1.1 , and the thread point me to use gdb-6.6 and all my pains went away. so my question is: will be GDB upgraded in the base system? or the buggy gdb-6.1.1 still be around? GDB 6.6 is in ports if you need a later version. I agree that the base gdb should be upgraded. On a related note, I've been using a manually compiled GDB 6.8 for Ada work on all my machines and haven't had any problems to date. xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Obytes counter in netstat not incrementing
On Tue, Sep 02, 2008 at 05:22:10PM -0700, Charles Beckham wrote: i've already made the changes to rc.conf, but since its a shared machine and almost all addresses are in use, i'll have to schedule a reboot before i can make changes effective, i will post a follwup after i've made these changes. thanks for you assistance. Be carefull with the mask - the primary should match the network range. Just additional ones need to be /32. If you are using multiple network ranges then you need multiple primary ones. I'm not a friend of large aliases on Ethernet anyway, since it just creates large ARP tables and wastes addresses (broadcast, ...). What I normaly do is configuring additional addresses (not part of any LAN) on lo0. Then you just route those addresses to the host. Using LAN IPs is just a workaround when you can't route IPs or other special requirements exists. One of the special requirement might be that the clients are distributed on the same LAN, so you don't want to pass everything over a router. But the typical case for such a large number of addresses are internet services and in that case everything has to pass your router anyway. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Creation of the NO_SSP build knob
On Fri, Sep 05, 2008 at 09:00:28AM +0200, Jeremie Le Hen wrote: Dag-Erling, On Thu, Sep 04, 2008 at 09:26:28PM +0200, Dag-Erling Sm?rgrav wrote: Jeremie Le Hen [EMAIL PROTECTED] writes: If SSP belongs to this list, then NO_SSP is an alias for WITHOUT_SSP. But it will still not be possible to use WITH_SSP in src.conf or command-line. [...] Shouldn't we have a knob that overrides whatever the user says, only for internal use in the source tree? That was my original intent when asking if I could add NO_SSP. That's *exactly* what NO_* does. Just add SSP to that list and replace WITHOUT_SSP with NO_SSP wherever it occurs in Makefiles in the tree. I've just tested it with NO_SSP and I can confirm it doesn't work despite the explicit comment above stating otherwise. By the way, the code is nearly identical between the supported options and the compat ones, I don't see how it could override the user settings: This is not the way the things were designed to work. http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html WITH_*/WITHOUT_* are for users, and MK_* are for makefiles. NO_*'s are mainly for backwards compatibility and (to the lesser extent) to support some of the makefile buzzwords like NO_MAN. There's no possibility to easily make what you want, i.e., disable SSP for some parts of the tree. Doing it for particular makefiles OTOH should be pretty easy, by starting a makefile with the following two lines: .include bsd.own.mk MK_SSP=no bsd.own.mk will set MK_SSP as per default (yes), then possibly reset it to no if a user set WITHOUT_SSP (either on a command line, in /etc/make.conf, or in environment), and then the second line will unconditionally reset it to no. This will work in the SSP case, but may not work in general because some options have dependencies. Fortunately, cases like this are rare. (There are several makefiles in the tree that already do this; grep ^MK_ to see them.) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Extending find(1) to support -printf
On Fri, Sep 05, 2008 at 03:12:53AM -0700, Jeremy Chadwick wrote: Also, some folks on #bsdports asked why I was bothering with this in the first place: mutt supports backticks to run shell commands inside of a muttrc file. See Building a list of mailboxes on the fly below: http://wiki.mutt.org/?ConfigTricks Note the find ... -printf '%h ' method. I can accomplish (just about) the same using `echo $HOME/Maildir/*`, but if I want to exclude an entry, I can't use | grep -v, because mutt doesn't support pipes within backticks. :-) Follow-up: mutt's backtick support does in fact respect pipes. My echo|grep -v was doing exactly what I requested: the grep -v was removing all output of the echo, since echo returned the results in a space-delimited format, not one per line. Hence, mailboxes was being executed without any arguments. Equally as frustrating, mutt's backtick support will only honour the first line of input. If a backticked command returns multiple lines, only the first is read; the rest are ignored. This makes using BSD find annoying, since find always outputs results terminated with a newline. One of my peers uses find | perl -ne 'chomp; print =, $_, ' to deal with this limit, which is quite disgusting. I realise there are workarounds for the dilemma (e.g. write a shell script that provides the exact output needed), but it seems like one could kill two birds with one stone by extending BSD find to support -printf, which does not output a newline unless \n is used within the output formatting. (This also explains why the Mutt Wiki entry uses -printf '%h ', note the space.) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Extending find(1) to support -printf
On Friday 05 September 2008 16:39, Jeremy Chadwick wrote: Equally as frustrating, mutt's backtick support will only honour the first line of input. If a backticked command returns multiple lines, only the first is read; the rest are ignored. This makes using BSD find annoying, since find always outputs results terminated with a newline. One of my peers uses find | perl -ne 'chomp; print =, $_, ' to deal with this limit, which is quite disgusting. It is, especially when you consider find ... | xargs (or find ... -print0 | xargs -0 if your filenames might cause problems (embedded spaces etc)). Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Creation of the NO_SSP build knob
Hi Ruslan,
On Fri, Sep 05, 2008 at 06:02:04PM +0400, Ruslan Ermilov wrote:
This is not the way the things were designed to work.
http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html
WITH_*/WITHOUT_* are for users, and MK_* are for makefiles.
NO_*'s are mainly for backwards compatibility and (to the lesser
extent) to support some of the makefile buzzwords like NO_MAN.
There's no possibility to easily make what you want, i.e., disable
SSP for some parts of the tree. Doing it for particular makefiles
OTOH should be pretty easy, by starting a makefile with the
following two lines:
.include bsd.own.mk
MK_SSP=no
bsd.own.mk will set MK_SSP as per default (yes), then possibly
reset it to no if a user set WITHOUT_SSP (either on a command
line, in /etc/make.conf, or in environment), and then the second
line will unconditionally reset it to no.
This will work in the SSP case, but may not work in general
because some options have dependencies. Fortunately, cases like
this are rare. (There are several makefiles in the tree that
already do this; grep ^MK_ to see them.)
Thank you for this clarification.
Unfortunately, I can't use MK_SSP in Makefile.inc1. The only option I
see is to override SSP_CFLAGS on ${BMAKE} and ${TMAKE} command-line.
There is also a problem with some Makefile.inc containing NO_SSP. It's
not possible to turn those to MK_SSP= no because bsd.init.mk includes
../Makefile.inc before bsd.own.mk.
Would you agree with the attached patch? Or would you prefer to use
SSP_CFLAGS everywhere?
Thank you!
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
Index: Makefile.inc1
===
RCS file: /mnt/octobre/space/freebsd-cvs/src/Makefile.inc1,v
retrieving revision 1.610
diff -u -p -r1.610 Makefile.inc1
--- Makefile.inc1 19 Aug 2008 14:23:26 - 1.610
+++ Makefile.inc1 5 Sep 2008 15:16:25 -
@@ -225,7 +225,7 @@ BMAKE= MAKEOBJDIRPREFIX=${WORLDTMP} \
${BMAKEENV} ${MAKE} -f Makefile.inc1 \
DESTDIR= \
BOOTSTRAPPING=${OSRELDATE} \
- -DWITHOUT_SSP \
+ SSP_CFLAGS= \
-DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN \
-DWITHOUT_NLS -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED \
-DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF
@@ -235,8 +235,9 @@ TMAKE= MAKEOBJDIRPREFIX=${OBJTREE} \
${BMAKEENV} ${MAKE} -f Makefile.inc1 \
TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \
DESTDIR= \
+ SSP_CFLAGS= \
BOOTSTRAPPING=${OSRELDATE} -DNO_LINT -DNO_CPU_CFLAGS \
- -DNO_WARNS -DNO_CTF -DWITHOUT_SSP
+ -DNO_WARNS -DNO_CTF
# cross-tools stage
XMAKE= TOOLS_PREFIX=${WORLDTMP} ${BMAKE} \
@@ -453,7 +454,7 @@ build32:
.if ${MK_KERBEROS} != no
.for _t in obj depend all
cd ${.CURDIR}/kerberos5/tools; \
- MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} -DWITHOUT_SSP DESTDIR= \
+ MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS= DESTDIR= \
${_t}
.endfor
.endif
@@ -476,7 +477,7 @@ build32:
.endfor
.for _dir in lib/ncurses/ncurses lib/ncurses/ncursesw lib/libmagic
cd ${.CURDIR}/${_dir}; \
- MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} -DWITHOUT_SSP DESTDIR= \
+ MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS= DESTDIR= \
build-tools
.endfor
cd ${.CURDIR}; \
@@ -765,14 +766,14 @@ buildkernel:
@echo --
cd ${KRNLOBJDIR}/${_kernel}; \
MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \
- ${MAKE} -DWITHOUT_SSP -DNO_CPU_CFLAGS -DNO_CTF \
+ ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \
-f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile
# XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case.
.if !defined(MODULES_WITH_WORLD) !defined(NO_MODULES) exists(${KERNSRCDIR}/modules)
.for target in obj depend all
cd ${KERNSRCDIR}/modules/aic7xxx/aicasm; \
MAKEOBJDIRPREFIX=${KRNLOBJDIR}/${_kernel}/modules \
- ${MAKE} -DWITHOUT_SSP -DNO_CPU_CFLAGS -DNO_CTF ${target}
+ ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF ${target}
.endfor
.endif
.if !defined(NO_KERNELDEPEND)
Index: gnu/lib/csu/Makefile
===
RCS file: /mnt/octobre/space/freebsd-cvs/src/gnu/lib/csu/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- gnu/lib/csu/Makefile 25 Jun 2008 21:33:28 - 1.29
+++ gnu/lib/csu/Makefile 5 Sep 2008 15:24:07 -
@@ -1,5 +1,8 @@
# $FreeBSD: src/gnu/lib/csu/Makefile,v 1.29 2008/06/25 21:33:28 ru Exp $
+.include bsd.own.mk
+MK_SSP= no
+
GCCDIR= ${.CURDIR}/../../../contrib/gcc
GCCLIB= ${.CURDIR}/../../../contrib/gcclibs
CCDIR= ${.CURDIR}/../../usr.bin/cc
@@ -19,7 +22,6 @@ CFLAGS+= -I${GCCLIB}/include -I${GCCDIR}
-I${CCDIR}/cc_tools
CRTS_CFLAGS= -DCRTSTUFFS_O -DSHARED ${PICFLAG}
MKDEP= -DCRT_BEGIN
-WITHOUT_SSP=
.if ${MACHINE_ARCH} == ia64
BEGINSRC= crtbegin.asm
Index: gnu/lib/libssp/Makefile
===
RCS
opendir()/closedir()
Looking at opendir()/readdir()/closedir() sequence via ktrace, I've seen supposedly useless lseek() syscall just before close(). It's called from closedir(): _seekdir(dirp, dirp-dd_rewind);/* free seekdir storage */ It seems that free()ing libc seekdir storage should be done without calling lseek(). Other strange place for me is stat() before open() in opendir() /* * stat() before _open() because opening of special files may be * harmful. _fstat() after open because the file may have changed. */ What is the case when opening special file may be harmful ? -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: opendir()/closedir()
On Fri, Sep 05, 2008 at 10:40:32PM +0400, Igor Sysoev wrote: Looking at opendir()/readdir()/closedir() sequence via ktrace, I've seen supposedly useless lseek() syscall just before close(). It's called from closedir(): _seekdir(dirp, dirp-dd_rewind);/* free seekdir storage */ It seems that free()ing libc seekdir storage should be done without calling lseek(). Other strange place for me is stat() before open() in opendir() /* * stat() before _open() because opening of special files may be * harmful. _fstat() after open because the file may have changed. */ What is the case when opening special file may be harmful ? For instance, tape may be rewinded. The whole opendir/seekdir/telldir probably should be synced with OpenBSD version, at least due to SINGLEUSE. I made this conclusion when I merged the OpenBSD fix for seekdir several months ago. But I also decided then that I am not a volunteer. pgpvmG7M13KyL.pgp Description: PGP signature
Re: opendir()/closedir()
On Fri, Sep 05, 2008 at 10:48:45PM +0300, Kostik Belousov wrote: On Fri, Sep 05, 2008 at 10:40:32PM +0400, Igor Sysoev wrote: Looking at opendir()/readdir()/closedir() sequence via ktrace, I've seen supposedly useless lseek() syscall just before close(). It's called from closedir(): _seekdir(dirp, dirp-dd_rewind);/* free seekdir storage */ It seems that free()ing libc seekdir storage should be done without calling lseek(). Other strange place for me is stat() before open() in opendir() /* * stat() before _open() because opening of special files may be * harmful. _fstat() after open because the file may have changed. */ What is the case when opening special file may be harmful ? For instance, tape may be rewinded. The whole opendir/seekdir/telldir probably should be synced with OpenBSD version, at least due to SINGLEUSE. I made this conclusion when I merged the OpenBSD fix for seekdir several months ago. But I also decided then that I am not a volunteer. BTW, OpenBSD does not worry about tapes :), they use open()/fstat() from the very start. And closedir() does not lseek() since OpenBSD 4.0. -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: opendir()/closedir()
On Sat, Sep 06, 2008 at 12:40:14AM +0400, Igor Sysoev wrote: On Fri, Sep 05, 2008 at 10:48:45PM +0300, Kostik Belousov wrote: On Fri, Sep 05, 2008 at 10:40:32PM +0400, Igor Sysoev wrote: Looking at opendir()/readdir()/closedir() sequence via ktrace, I've seen supposedly useless lseek() syscall just before close(). It's called from closedir(): _seekdir(dirp, dirp-dd_rewind);/* free seekdir storage */ It seems that free()ing libc seekdir storage should be done without calling lseek(). Other strange place for me is stat() before open() in opendir() /* * stat() before _open() because opening of special files may be * harmful. _fstat() after open because the file may have changed. */ What is the case when opening special file may be harmful ? For instance, tape may be rewinded. The whole opendir/seekdir/telldir probably should be synced with OpenBSD version, at least due to SINGLEUSE. I made this conclusion when I merged the OpenBSD fix for seekdir several months ago. But I also decided then that I am not a volunteer. BTW, OpenBSD does not worry about tapes :), they use open()/fstat() from the very start. And closedir() does not lseek() since OpenBSD 4.0. This was my point. They reworked the code, and it seems that rework brought in improvements, that are aligned with your observations. pgpr4C37fVm2F.pgp Description: PGP signature
Temp files in /etc
Hi all, I am setting up a few jails and I want them all to use the same /etc files (with the exception of the files related to the password files and databases), so I mounted a shared /etc folder as a nullfs with read-only permissions. The problem is that using utilities like pw or chpass create temporary files in /etc and that file system is mounted read-only. So is there a way to force any utilities that create temp files in /etc to use another location, something like /usr/local/etc for example? ~Joshua ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Temp files in /etc
On Fri, Sep 05, 2008 at 07:40:13PM -0700, Joshua Piccari wrote: Hi all, I am setting up a few jails and I want them all to use the same /etc files (with the exception of the files related to the password files and databases), so I mounted a shared /etc folder as a nullfs with read-only permissions. The problem is that using utilities like pw or chpass create temporary files in /etc and that file system is mounted read-only. So is there a way to force any utilities that create temp files in /etc to use another location, something like /usr/local/etc for example? It depends entirely on how each individual program makes temporary files; there is no standard. libc offers a many different methods of creating temporary files: tmpfile(3), tmpnam(3), tempnam(3), mktemp(3), and mkstemp(3). You can read the manpages to get an idea of how chaotic the situation is. Other programs may implement their own temporary file creation methods entirely, and may/may not support TMPDIR. I would try export TMPDIR=/some/place and then attempt using pw and chpass, and see what happens. If they still attempt to use /tmp, said programs could probably be modified to support TMPDIR. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
