Re: Safe sourcing of rc files
On Mon 2000-04-10 (00:10), Doug Barton wrote:
> +if [ -z "${sourcercs_defined}" ]; then
> +sourcercs_defined=yes
> +sourcercs ( ) {
> +local sourced_files
> +for i in ${rc_conf_files}; do
> +case "${sourced_files}" in
> +*:$i:*)
> +;;
> +*)
> +sourced_files="${sourced_files}:$i:"
> +if [ -r $i ]; then
> +. $i
> +fi
> +;;
> +esac
> +done
> +}
> +fi
I have another idea: We make a sh script named "rcsource" or whatever,
which we source when we want to have the rc environment, stealing your
code maliciously:
/--
sourcercs_sourced_files=
sourcercs ( ) {
local rc_conf_files
for i in $*; do
case "${sourcercs_sourced_files}" in
*:$i:*)
;;
*)
sourcercs_sourced_files="${sourcercs_sourced_files}:$i:"
echo $i
if [ -r $i ]; then
. $i
sourcercs ${rc_conf_files}
fi
;;
esac
done
}
sourcercs /etc/defaults/rc.conf
\--
Anyway, this'll do something I've been considering missing - the ability
to set more rc_conf_files in /etc/rc.conf and friends. It also means a
total lack of sh-script in /etc/defaults/rc.conf and /etc/rc.conf, which
means that we can start developing something in C that can read those
files (libconf, Daniel?).
Basically, it localizes rc_conf_files so that you don't lose any you've
specified before. So, in /etc/defaults/rc.conf, it sets rc_conf_files
to "/etc/rc.conf /etc/rc.conf.local", and when it runs /etc/rc.conf,
rc_conf_files changes to "/etc/foo.conf", and that'll be read. After
it's finished, it pops up two spaces, and goes on to /etc/rc.conf.local.
A file will only ever be sourced once.
One possible extension may be a specifier of a preprocessor for a file:
preprocessor__etc_defaults_rc.conf='cpp' will be checked if sourcercs is
run on /etc/defaults/rc.conf, and it will be passed through cpp before
trying to understand it. This should be extensible enough to avoid the
need of sh-script to get a value for a variable.
Any more ideas?
Neil
--
Neil Blakey-Milner
Hacker In Chief, Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS attribute cache & profiling sysctl variables
On Sun, 16 Apr 2000, Andrzej Bialecki wrote:
> On Sat, 15 Apr 2000, Zhihui Zhang wrote:
>
> >
> > I have two unrelated questions I can not figure out myself:
>
> > (2) I am trying to display kernel profiling sysctl variables with sysctl
> > -a or sysctl -A without success. They are defined in subr_prof.c. Why
> > sysctl command can not display them? I can use kgmon.
>
I spend some time on this. It turns out that you can not do a sysctl() on
a node without a handler. For the case of kern.prof, there is a handler,
but that handler - sysctl_kern_prof() - only allows you to access lower
level variables.
When you do sysctl -a or sysctl -A, you use the special {0,2, ..} names to
get the next oids in the MIB tree. In the routine
sysctl_sysctl_next_ls(), you can see that a node with a handler is skipped
by the following statements:
if ((oidp->oid_kind & CTLTYPE) != CTLTYPE_NODE)
continue;
if (oidp->oid_handler)
continue;
That is why you can not show kern.prof stuff with command sysctl -a or
sysctl -A. You have to use the way shown in usr.sbin/kgmon/kgmon.c.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Questions of the syncer process
I have two questions related to the syncer process that replaces the old update process: (1) The syncer process is waken up once a second (it sleeps on lbolt). If I have more than 30 mounted filesystems, then each filesystem's dirty data will stay more than 30 seconds. If I only have a couple of filesystems, then the syncer will run more frequenty than the old update process. Is this a good choice? (2) I do not understand why vfs_msync(mp, MNT_NOWAIT) is called before VFS_SYNC(mp, MNT_LAZY,...). It seems to me that the latter includes the work done by the former. Thanks for any insights into this subject. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Safe sourcing of rc files
On Wed, 19 Apr 2000, Neil Blakey-Milner wrote: > I have another idea: We make a sh script named "rcsource" or whatever, > which we source when we want to have the rc environment, [snip] > One possible extension may be a specifier of a preprocessor for a file: > > preprocessor__etc_defaults_rc.conf='cpp' will be checked if sourcercs is > run on /etc/defaults/rc.conf, and it will be passed through cpp before > trying to understand it. This should be extensible enough to avoid the > need of sh-script to get a value for a variable. > > Any more ideas? I was in complete agreement with you until you got to the preprocessor. (I've previously advocated something similar) However, IMHO, even considering using cpp as a preprocessor will never fly. The configuration mechanism MUST be small and simple. cpp isn't even available when you start. (You only get things in /bin and /sbin, and cpp certainly has no place there) If you want a preprocessor, I suggest the sendmail approach where you write the definitions in some meta-language and preprocess that into simple sh definitions. That way, you don't need the preprocessor at run time. Besides, if people would learn the language, 'sh' is really quite powerful. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Questions of the syncer process
: :I have two questions related to the syncer process that replaces the old :update process: : :(1) The syncer process is waken up once a second (it sleeps on lbolt). If :I have more than 30 mounted filesystems, then each filesystem's dirty data :will stay more than 30 seconds. If I only have a couple of filesystems, :then the syncer will run more frequenty than the old update process. Is :this a good choice? The filesystem sync time has nothing to do with the number of mounted filesystems. Every dirty vnode is added to the syncer list and placed in a specific delay slot. The syncer gets to it in that amount of time no matter how many mounted filesystems there are - usually every 30 seconds or so. :(2) I do not understand why vfs_msync(mp, MNT_NOWAIT) is called before :VFS_SYNC(mp, MNT_LAZY,...). It seems to me that the latter includes the :work done by the former. : :Thanks for any insights into this subject. : :-Zhihui Even though we have a unified buffer cache, we do not have unified bookeeping. vfs_msync() is responsible for converting the bookeeping on dirty VM pages into bookeeping on filesystem buffers. That is, if it finds a dirty VM page it ensures that there is a dirty filesystem buffer header associated with it. Otherwise the filesystem will not know they are dirty. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Safe sourcing of rc files
On Wed, Apr 19, 2000, Neil Blakey-Milner wrote:
> On Mon 2000-04-10 (00:10), Doug Barton wrote:
> > +if [ -z "${sourcercs_defined}" ]; then
> > +sourcercs_defined=yes
> > +sourcercs ( ) {
> > +local sourced_files
> > +for i in ${rc_conf_files}; do
> > +case "${sourced_files}" in
> > +*:$i:*)
> > +;;
> > +*)
> > +sourced_files="${sourced_files}:$i:"
> > +if [ -r $i ]; then
> > +. $i
> > +fi
> > +;;
> > +esac
> > +done
> > +}
> > +fi
>
> I have another idea: We make a sh script named "rcsource" or whatever,
> which we source when we want to have the rc environment, stealing your
> code maliciously:
Yup, thats what I proposed, and this code is basically what I had hacked
at my end. :)
Adrian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Questions of the syncer process
On Wed, 19 Apr 2000, Matthew Dillon wrote: > : > :I have two questions related to the syncer process that replaces the old > :update process: > : > :(1) The syncer process is waken up once a second (it sleeps on lbolt). If > :I have more than 30 mounted filesystems, then each filesystem's dirty data > :will stay more than 30 seconds. If I only have a couple of filesystems, > :then the syncer will run more frequenty than the old update process. Is > :this a good choice? > > The filesystem sync time has nothing to do with the number of > mounted filesystems. Every dirty vnode is added to the syncer > list and placed in a specific delay slot. The syncer gets to > it in that amount of time no matter how many mounted filesystems > there are - usually every 30 seconds or so. Thanks for your response. I reread the code and find out individual dirty vnodes can be put on the worklist. But why do we put the syncer vnodes on the worklist as well? It seems to me that they are there to make sure that each entire filesystem is sync'ed once in while. Since individual dirty vnodes have already been sync'ed, I do not know why it is necessary. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
video on its side
Hiya all, Let's see, how do I frame this question? Well, let me tell you what I'd like to do and maybe folks could gently push me in the right direction. :) I want to take a monitor running at 640x480 and physically turn it on its side (yes, I *can* do this :) and then I want to display the text on the screen in that orientation ie. 480x640. I'd also like to be able to change the number of rows and columns to something like 55 columns by 45 lines. Text only applications, X need not apply. I'm not quite sure where to begin. I've been reading over man pages and everything I've found so far hasn't said diddly boo about it unless I'm missing something blindingly obvious (entirely possible). I haven't seen nor could I find anything in the mailing list archives either. I'm guessing that a new font that fits my dimensions will be needed and maybe a partial rewrite of a display driver? Apologies if this should be posted to hardware. Be gentle, newbie with this stuff. ;) Russ Pagenkopf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #814
unsubscribe freebsd-hackers-digest To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cscope open-sourced!
FYI, For those who haven't heard, cscope has been open-sourced by SCO (under a BSD-style license, no less)! See: http://cscope.sourceforge.net/ I've got patches for FreeBSD, as well as a couple bugfixes, in case anyone wants to turn this into a port (I don't have the time, sorry). -- Darryl Okahata [EMAIL PROTECTED] http://web.sr.hp.com/~darrylo/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sigjmp_buf question
Where does one look in the source for the definition of what each of the ints in sigjmp_buf._sjb (or jmp_buf._jb for that matter) contain? The only occurrences of it (according to grep(1)) are in the header file machine/setjmp.h. I also looked into src/sys/i386/i386/machdep.c and didn't see anything that struck me as being what I'm looking for. TIA. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sigjmp_buf question
On Wed, Apr 19, 2000 at 09:39:44PM -0500, Steve Price wrote: > Where does one look in the source for the definition of what > each of the ints in sigjmp_buf._sjb (or jmp_buf._jb for that > matter) contain? The only occurrences of it (according to > grep(1)) are in the header file machine/setjmp.h. I also > looked into src/sys/i386/i386/machdep.c and didn't see anything > that struck me as being what I'm looking for. Look into src/lib/libc/i386/gen/_setjmp.S and other files in the same directory for setjmp() and sigsetmp(). Basically, it'll store edx, ebx, esp, ebp, esi, edi, and the CPU control word, in that order. -- Anatoly Vorobey, [EMAIL PROTECTED] http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FTP_PASSIVE_MODE and libftpio
In reference to a problem someone reported on the freebsd-mobile mailing list, I took a look at the handling of the FTP_PASSIVE_MODE environment variable in libftpio. What I found was that it would use passive ftp based on if the environment variable was set or not and didn't acutally check it's value. I wrote a patch for it that makes it also consider the value of the variable. This will save some confusion for people that follow the login that since FTP_PASSIVE_MODE=YES seems to make ftp use passive mode that FTP_PASSIVE_MODE=NO should make it not use passive mode. This isn't the case with the current handling of it. Please take a look at the PR I put together bin/18103 and let me know if this is a good (enough) fix for the problem. The patch can aslo be found at: http://quake.nyct.net/~efutch/FreeBSD/ftpio.c.patch Sorry for the cross post. I'm not exactly sure what's the best mailing list for this. Thanks to Ross A Lippert <[EMAIL PROTECTED]> for pointing this out. -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Corrupted disk label and related issues (fwd)
I sent this to freebsd-questions yesterday, and didn't get any responses...looks like Andrew had a similar situation about a month ago, and found a solution which I'm trying to adapt to my own problem. Thing is, I can't even get to the individual partitions like he did -- I keep getting "Device not configured" and the like. Any advice? - Forwarded message from "J.D. Falk" <[EMAIL PROTECTED]> - Date: Wed, 19 Apr 2000 03:47:48 -0700 From: "J.D. Falk" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Corrupted disk label and related issues Message-ID: <[EMAIL PROTECTED]> Yesterday a drive which I'd been meaning to replace died in a generally unhappy manner -- after much research and general (mostly unrelated) replacement of hardware, I (with help from some friends) tracked it down to disklabel problems and did a bunch of work trying to fix that. The way things stand now, `disklabel -r ad3` comes up with the correct information about eight times out of ten; other times, it'll say "bad pack magic number (label is damaged, or pack is unlabeled)". I managed to dd the entire contents of the disk to another, more functional slice elsewhere. So, the data is still all there in one form or another. If I could find out the exact start (after boot foo) of the partitions, I could dd each of them seperately and work from there, but I'm not sure if it'd really buy me all that much. Another possible datapoint: attempting to mount or fsck any of the partitions will, more often than not, result in a "Device not configured" message. My main goal at this point, after more than sixteen hours of working on it and nearly 25 hours of downtime -- is to regain the data. If anyone could offer advice, I sure would appreciate it. I have a feeling that I'm missing something simple -- I used to be a sysadmin, but I never had this kind of problem with a BSD system before. *sigh* (Note: the machine in question is my own, not my employer's.) - End forwarded message - -- J.D. Falk "Laughter is the sound Product Manager that knowledge makes when it's born." Mail Abuse Prevention System LLC -- The Cluetrain Manifesto To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Corrupted disk label and related issues (fwd)
In message <[EMAIL PROTECTED]> "J.D. Falk" writes:
: I sent this to freebsd-questions yesterday, and didn't get any
: responses...looks like Andrew had a similar situation about a
: month ago, and found a solution which I'm trying to adapt to
: my own problem. Thing is, I can't even get to the individual
: partitions like he did -- I keep getting "Device not configured"
: and the like. Any advice?
Well, you might be able to use the following program, supplied on an
as is basis, to recover your disklabel. I wrote it when I
accidentally overwrote the first 32k of my drive. Good thing only the
disklabel and fdisk partition happened to be there :-(. I've not
verified this program recently, so I have no clue if it will work for
you.
Oh, I dumped the disk to tape with dd before messing with it. Backup
any critical data before you attempt to use this program (although it
doesn't actually try to write anything you never know). You are
definitely on your own here and anything bad this program does is not
my fault, so don't whine to me if you ruin your already busted disk
with it.
Disclaimer, stolen from a darkendeavors promo spot: use only as
directed. Side effects may include incapacitation from nausea and
incessant hiccups, sporadic nostril insect infestation, terminal
Tarzanian Foot Fungus, excessively elongated ear lobes, contagious
reptilian laughter, digit loss, hemorrhagic episodes, full frontal
nudity, and an uncontrollable passion for DOS batch files. Pregnant
women should not skydive while listening. Read instructions at the
website: darkendeavors.com.
Warner
#include
#include
#include
#include
#include
#include
#include
#include
void
usage()
{
errx(1, "reclab fn");
}
ssize_t
read_good(int fd, void *addr, size_t sz)
{
ssize_t rv;
rv = read(fd, addr, sz);
if (rv < 0)
err(1, "read_good");
return rv;
}
int
search(int fd)
{
char buf[SBSIZE];
struct fs *fs = (struct fs *) buf;
off_t i = 0;
char ch = 'a';
while (read_good(fd, (void *) &buf, SBSIZE) == SBSIZE) {
if (i % 2048 == 0) {
printf("%qd MB\r", i/2048);
fflush(stdout);
}
i++;
lseek(fd, i * 512, SEEK_SET);
if (fs->fs_magic != FS_MAGIC)
continue;
printf("%c: %d %qd 4.2BSD 0 0 0 # %s %d\n", ch, fs->fs_size * 2,
i - 1 - 16, fs->fs_fsmnt, fs->fs_sblkno);
ch++;
if (ch == 'b')
ch = 'd';
i += 2 * fs->fs_size - 1;
lseek(fd, i * 512, SEEK_SET);
}
return (1);
}
int
main(int argc, char **argv)
{
int fd;
if (argc != 2)
usage();
fd = open(argv[1], O_RDONLY);
if (fd < 0)
err(1, "open");
search(fd);
close(fd);
return 0;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
