freebsd-hackers Digest, Vol 70, Issue 4
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Re: "Next Generation" kernel configuration? (Avleen Vig)
2. Re: "Next Generation" kernel configuration? (Devon H. O'Dell)
3. Re: Getting a fully-qualified path from a PID (Dan Nelson)
4. Re: "Next Generation" kernel configuration? (Andrew Konstantinov)
5. Re: "Next Generation" kernel configuration? (Anish Mistry)
6. Re: "Next Generation" kernel configuration? (M. Warner Losh)
7. Re: "Next Generation" kernel configuration? (Bruce R. Montague)
8. Re: "Next Generation" kernel configuration? (Avleen Vig)
9. Re: disk recovery help (Peter Jeremy)
10. Re: "Next Generation" kernel configuration? (Conrad J. Sabatier)
11. Re: "Next Generation" kernel configuration? (Conrad J. Sabatier)
12. Re: Getting a fully-qualified path from a PID (Joe Marcus Clarke)
----------------------------------------------------------------------
Message: 1
Date: Wed, 21 Jul 2004 05:43:45 -0700
From: Avleen Vig <lists-...@silverwraith.com>
Subject: Re: "Next Generation" kernel configuration?
To: "Conrad J. Sabatier" <con...@cox.net>
Cc: freebsd...@freebsd.org
Message-ID: <20040721124...@silverwraith.com>
Content-Type: text/plain; charset=us-ascii
On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote:
> Just musing on an idea here:
>
> I've been thinking for a while now about trying to write a tool to make
> kernel configuration easier, sort of a "make config" (as in ports) for
> the kernel, similar to what's available on some of the Linux distros.
I've read over the other posts in this thread, but I cannot say I think
this is a good idea. In fact, I think it's a very bad idea, but with
very good intentions. Here's why..
I'm a strong proponent of user education. The FreeBSD handbook is one of
the best education tools for someone who wants to use FreeBSD, right
from beginner to more advanced levels.
A "config tool", while useful for beginners, would quickly result is
those beginners not learning about building a kernel themselves, copying
GENERIC to `hostname -s | tr "[:lower:]" "[:upper:]"`, editing it,
learning what is in LINT, remembering to look through there, etc.
This process teaches users a lot about how a BSD kernel is configured,
what options are availible, and where to look for more options.
The end result would be more people building kernels themselves, but not
knowing what is actually happening, or what more is possible. It would
mean less educated users, and I don't think that is somewhere any
organization needs to go (look at what happened to the average Microsoft
user's IQ level, after people stopped using DOS and started having
machines do the work for them).
Like I said, I think your intentions are good, but I have concerns about
the suggested solution.
------------------------------
Message: 2
Date: Wed, 21 Jul 2004 14:52:07 +0200
From: "Devon H. O'Dell" <dod...@sitetronics.com>
Subject: Re: "Next Generation" kernel configuration?
To: Avleen Vig <lists-...@silverwraith.com>
Cc: freebsd...@freebsd.org
Message-ID: <40FE66F7...@sitetronics.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Avleen Vig wrote:
> On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote:
>
>>Just musing on an idea here:
>>
>>I've been thinking for a while now about trying to write a tool to make
>>kernel configuration easier, sort of a "make config" (as in ports) for
>>the kernel, similar to what's available on some of the Linux distros.
>
>
> I've read over the other posts in this thread, but I cannot say I think
> this is a good idea. In fact, I think it's a very bad idea, but with
> very good intentions. Here's why..
>
> I'm a strong proponent of user education. The FreeBSD handbook is one of
> the best education tools for someone who wants to use FreeBSD, right
> from beginner to more advanced levels.
>
> A "config tool", while useful for beginners, would quickly result is
> those beginners not learning about building a kernel themselves, copying
> GENERIC to `hostname -s | tr "[:lower:]" "[:upper:]"`, editing it,
> learning what is in LINT, remembering to look through there, etc.
> This process teaches users a lot about how a BSD kernel is configured,
> what options are availible, and where to look for more options.
>
> The end result would be more people building kernels themselves, but not
> knowing what is actually happening, or what more is possible. It would
> mean less educated users, and I don't think that is somewhere any
> organization needs to go (look at what happened to the average Microsoft
> user's IQ level, after people stopped using DOS and started having
> machines do the work for them).
>
> Like I said, I think your intentions are good, but I have concerns about
> the suggested solution.
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>
I wholly disagree. I think using an excuse ``people will let everything
else do the work for them and nobody will ever learn'' to discourage the
development of automation tools is very poor. Try applying that argument
to any utility that you use. You'd have to write your own bloody
operating system because ``learning's in your best interest''.
I'm sure this will become another bikeshed, so I suggest whoever came up
with the idea to put up or shut up. People are interested in solutions,
not suggestions.
--Devon
------------------------------
Message: 3
Date: Wed, 21 Jul 2004 10:12:20 -0500
From: Dan Nelson <dne...@allantgroup.com>
Subject: Re: Getting a fully-qualified path from a PID
To: Joe Marcus Clarke <mar...@marcuscom.com>
Cc: hac...@freebsd.org
Message-ID: <20040721151...@dan.emsphone.com>
Content-Type: text/plain; charset=us-ascii
In the last episode (Jul 20), Joe Marcus Clarke said:
> What is the canonical way for a userland application to get the
> fully-qualified path of an executable from its running PID? I know I
> can do a readlink(2) on /proc/pid/file, but procfs is deprecated on
> 5.X, correct? Is there a more appropriate way to do this? Thanks.
realpath(argv[0]) works for commands not run from $PATH. Commands found
through a PATH earch will just have the basename in argv[0] so you
would have to check each PATH element until you found it. Note that
/proc/pid/file won't work if vn_fullpath() fails (say the orignal file
has been unlinked, or the filename has expired from the kernel's
cache).
If you are examining another process, you can use the kvm_getargv() and
kvm_getenvv() functions to fetch argv[0] and PATH out of the target
process.
--
Dan Nelson
dne...@allantgroup.com
------------------------------
Message: 4
Date: Wed, 21 Jul 2004 10:00:19 -0700
From: Andrew Konstantinov <abkonst...@earthlink.net>
Subject: Re: "Next Generation" kernel configuration?
To: freebsd...@freebsd.org
Message-ID: <20040721170...@root.kableu.com>
Content-Type: text/plain; charset="us-ascii"
On Wed, Jul 21, 2004 at 05:43:45AM -0700, Avleen Vig wrote:
> On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote:
> > Just musing on an idea here:
> >
> > I've been thinking for a while now about trying to write a tool to make
> > kernel configuration easier, sort of a "make config" (as in ports) for
> > the kernel, similar to what's available on some of the Linux distros.
>
> I've read over the other posts in this thread, but I cannot say I think
> this is a good idea. In fact, I think it's a very bad idea, but with
> very good intentions. Here's why..
>
> I'm a strong proponent of user education. The FreeBSD handbook is one of
> the best education tools for someone who wants to use FreeBSD, right
> from beginner to more advanced levels.
>
> A "config tool", while useful for beginners, would quickly result is
> those beginners not learning about building a kernel themselves, copying
> GENERIC to `hostname -s | tr "[:lower:]" "[:upper:]"`, editing it,
> learning what is in LINT, remembering to look through there, etc.
> This process teaches users a lot about how a BSD kernel is configured,
> what options are availible, and where to look for more options.
>
> The end result would be more people building kernels themselves, but not
> knowing what is actually happening, or what more is possible. It would
> mean less educated users, and I don't think that is somewhere any
> organization needs to go (look at what happened to the average Microsoft
> user's IQ level, after people stopped using DOS and started having
> machines do the work for them).
>
> Like I said, I think your intentions are good, but I have concerns about
> the suggested solution.
I think such a tool would actually influence user education in a positive way.
Here is a sample scenario:
1) User starts this "program" to configure the kernel
2) User sees unknown to him option
3) User decides to look it up on www.google.com
4) "That's a nice feature, although I don't really need it"
5) GOTO 1
The only suggestion I have is to make it a third party program and not build it
into the make procedure for the kernel. It would look like pkg_tree that's
located in ports, although with a better ncurses interface.
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040721/bef9b3a2/attachment-0001.bin
------------------------------
Message: 5
Date: Wed, 21 Jul 2004 13:26:16 -0400
From: Anish Mistry <mist...@osu.edu>
Subject: Re: "Next Generation" kernel configuration?
To: freebsd...@freebsd.org
Message-ID: <200407211326....@osu.edu>
Content-Type: Text/Plain; charset="iso-8859-1"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 21 July 2004 01:00 pm, Andrew Konstantinov wrote:
> On Wed, Jul 21, 2004 at 05:43:45AM -0700, Avleen Vig wrote:
> > On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote:
> > > Just musing on an idea here:
> > >
> > > I've been thinking for a while now about trying to write a tool to make
> > > kernel configuration easier, sort of a "make config" (as in ports) for
> > > the kernel, similar to what's available on some of the Linux distros.
> >
> > I've read over the other posts in this thread, but I cannot say I think
> > this is a good idea. In fact, I think it's a very bad idea, but with
> > very good intentions. Here's why..
> >
> > I'm a strong proponent of user education. The FreeBSD handbook is one of
> > the best education tools for someone who wants to use FreeBSD, right
> > from beginner to more advanced levels.
> >
> > A "config tool", while useful for beginners, would quickly result is
> > those beginners not learning about building a kernel themselves, copying
> > GENERIC to `hostname -s | tr "[:lower:]" "[:upper:]"`, editing it,
> > learning what is in LINT, remembering to look through there, etc.
> > This process teaches users a lot about how a BSD kernel is configured,
> > what options are availible, and where to look for more options.
> >
> > The end result would be more people building kernels themselves, but not
> > knowing what is actually happening, or what more is possible. It would
> > mean less educated users, and I don't think that is somewhere any
> > organization needs to go (look at what happened to the average Microsoft
> > user's IQ level, after people stopped using DOS and started having
> > machines do the work for them).
> >
> > Like I said, I think your intentions are good, but I have concerns about
> > the suggested solution.
>
> I think such a tool would actually influence user education in a positive
> way. Here is a sample scenario:
>
> 1) User starts this "program" to configure the kernel
> 2) User sees unknown to him option
> 3) User decides to look it up on www.google.com
> 4) "That's a nice feature, although I don't really need it"
> 5) GOTO 1
>
> The only suggestion I have is to make it a third party program and not
> build it into the make procedure for the kernel. It would look like
> pkg_tree that's located in ports, although with a better ncurses interface.
>
> Andrew
I think a tool with the functionality described in the original post would be
very nice, but it shouldn't be menu driven etc. Something more like a kernel
dependency checker that would take the kernel config file, and check that all
the dependencies are correct. ie. for umass you need da, but if you forget
you'll only get a cryptic failing of the kernel build. Also for things like
bktr, which you need to have iic and friends.
Something along the lines of a command line "make depend-check" before you do
a make kernel would be nice.
- --
Anish Mistry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA/qc/xqA5ziudZT0RAhLQAJ9HvvtFjmvOkP7hCX4nNR4LGbeMmACgr4vi
gQGqNJyVysUTFlisDYohF+8=
=gXI8
-----END PGP SIGNATURE-----
------------------------------
Message: 6
Date: Wed, 21 Jul 2004 12:12:15 -0600 (MDT)
From: "M. Warner Losh" <i...@bsdimp.com>
Subject: Re: "Next Generation" kernel configuration?
To: murray...@bytecraftsystems.com
Cc: m...@love2party.net
Message-ID: <20040721.12121...@bsdimp.com>
Content-Type: Text/Plain; charset=us-ascii
In message: <1090393301.2...@wstaylorm.dand06.au.bytecraft.au.com>
Murray Taylor <murray...@bytecraftsystems.com> writes:
: As an initial starting point for 'preloading' any menubased kernel
: configurator, could the file /var/run/dmesg.boot be usefully parsed as
: a list of 'this is what is actually installed in this box, what else do
: you want to add?" Of course any output developed on a run of the
: configurator would/could/should be scanned as well to include answers to
: the question.."What did I include last time?"
if devd could map, somehow, the pnp info into drivers to load, that
would solve this problem.
warner
------------------------------
Message: 7
Date: Wed, 21 Jul 2004 13:41:05 -0700 (PDT)
From: "Bruce R. Montague" <bru...@mail.cruzio.com>
Subject: Re: "Next Generation" kernel configuration?
To: freebsd...@freebsd.org
Message-ID: <200407212041....@mail.cruzio.com>
Hi, re, "Next Generation" kernel configuration:
Years ago I had a job for a few years where I
constantly built RSX-11 systems on PDP-11s. RSX-11
was always built from source and had a couple of
hundred build-time options, many hardware build
dependencies, and supported numerous other dynamic
build-time functions; it was said that it was possible
that no 2 RSX systems were really the same binaries.
It may have been more combinatorially complex than
FreeBSD. An RSX build could easily take a day.
Although at the core the build was driven by a file
of assembly macro defines, conceptually not unlike
FreeBSD, the build process went through continuous
evolution over the life of RSX. A comprehensive
"sysgen.bat" script, or somesuch, evolved. Sysgen
(which was a common industry term at the time) was
a very large script that was intended to be run on
a fast hard-copy decwriter; it printed out lists of
possibilities and then asked you a question, you
made a selection from the options, and so on. It
conducted a 'scripted dialog' that reflected the
options you made along the way. You wanted this on
hard copy so you could go back and check things,
keep it for next time, and so on. You could go back
in the dialog and repeat a section, save the sysgen
state and restart later, and so on.
A sysgen dialog could easily take half-a-day (sometimes
intermediate things had to be built and such), and
then the build itself and install could take a number
of hours...
At the end of the sysgen dialog you could "save the
session", basically, and then the next time you did
a session you could ask to use the saved session and
essentially conduct a "modification dialog". Working
with sysgen often felt like taking part in an adventure
game with an AI opponent; you had to know how to
outsmart the script to get it to do exactly what you
wanted. This might be a common failing of many
pseudo AI type programs.
On the one had this all worked and worked well. On
the other hand if you can do it by simply editing
flat files it's much better, because you don't have
to become an expert on the sysgen script just to do
a build. Back on the other hand, there may be a point
of complexity (and lack of corresponding widespread
sophistication) where a sysgen program is necessary.
SO:
If a sysgen-like program was built for FreeBSD that
used a conversational, graphic, menu, or whatever
interface, instead of actually doing anything to
real files or the real system, could it just print
out _what to do_, that is, it would output a list
of instructions - in such-and-such a file, edit this
option, then add this line... Or perhaps it would
output diffs to files... or put the output in a
"candidate" location. But in any case the program
would be a SYSGEN ASSISTANT, not an actual sysgen
program. Basically a "kernel config checker", a smart
build-lint, etc.. It could live in ports. If this
program got to where it really worked, everyone liked
the interface, and the system complexity was clearly
at the point where it was needed, it could be used
to directly generate system configurations.
The dependency-rule evaluation and output part could
be built independent of any user-interface, so a
front-end back-end scheme might make sense.
In any case, googling on "RSX sysgen" might produce
some ideas of interest. BTW, I'm under the impression
that for quite some time the largest rule-based AI
application ("real-time expert system") in the world
was the OPS5 system implemented at DEC to configure
VAX hardware, see links such as:
http://encyclopedia.thefreedictionary.com/OPS5%20rule%20based
It looks like there's a public domain system that
compiles rules to C code, perhaps there are some
interesting ideas there as well for things like
general dependency rule evaluation in the backend
and such:
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/expert/systems/ops5/0.html
Sorry to go on at length.
- bruce
------------------------------
Message: 8
Date: Thu, 22 Jul 2004 00:42:11 -0700
From: Avleen Vig <lists-...@silverwraith.com>
Subject: Re: "Next Generation" kernel configuration?
To: "Devon H. O'Dell" <dod...@sitetronics.com>
Cc: freebsd...@freebsd.org
Message-ID: <20040722074...@silverwraith.com>
Content-Type: text/plain; charset=us-ascii
On Wed, Jul 21, 2004 at 02:52:07PM +0200, Devon H. O'Dell wrote:
> I wholly disagree. I think using an excuse ``people will let everything
> else do the work for them and nobody will ever learn'' to discourage the
> development of automation tools is very poor. Try applying that argument
> to any utility that you use. You'd have to write your own bloody
> operating system because ``learning's in your best interest''.
> I'm sure this will become another bikeshed, so I suggest whoever came up
> with the idea to put up or shut up. People are interested in solutions,
> not suggestions.
You confuse automation, with simplification.
Automation tools are good for frequently re-run tasks.
How often do you recompile your kernel?
.... exactly.
--
Avleen Vig
Systems Administrator
Personal: www.silverwraith.com
EFnet: irc.mindspring.com (Earthlink user access only)
------------------------------
Message: 9
Date: Thu, 22 Jul 2004 17:57:23 +1000
From: Peter Jeremy <Peter...@optushome.com.au>
Subject: Re: disk recovery help
To: Charles Sprickman <sp...@fasttrackmonkey.com>
Cc: freebsd...@freebsd.org
Message-ID: <2004072207...@cirb503493.alcatel.com.au>
Content-Type: text/plain; charset=us-ascii
On Tue, 2004-Jul-20 14:01:06 -0400, Charles Sprickman wrote:
>On Tue, 20 Jul 2004, Peter Jeremy wrote:
>
>> It's difficult to see how a sanely written RAID utility could totally
>> screw up an array in a short time
Upon reflection, one obvious way is to change the array layout. I
don't know enough about your configuration and Adaptec's raidutil to
know if this is likely.
>command does, but they are fairly certain that it writes it's config at
>the end of the disk, then zeros it from the outside in.
Which puts an upper limit on the amount of damage done. The only
difficulty with this is that (ISTR) your filesystem begins at the
beginning of the array so the primary superblock should be the first
thing over-written - and fsck would whinge loudly about that.
>grabbed the dd "image" before that. An fsck on the problem partition ran
>for 12 hours and I don't know how far along it was.
Ctrl-T (aka SIGINFO) is your friend - fsck will tell you how far
through its current phase it is.
> I looked at scan_ffs
>just now, and it looks like it works on the whole disk trying to find the
>label. Since I only have one partition, there's no label.
scan_ffs searches the disk (or file) looking for UFS superblocks. The
most common reason for needing this is to re-generate your partition
tables. I was hoping it would also locate all the superblocks - which
would let you verify that the structure looked reasonably sane.
You might also try fsdb(8) - though I think it relies on the primary
superblock being sane.
Good luck.
--
Peter Jeremy
------------------------------
Message: 10
Date: Thu, 22 Jul 2004 06:43:40 -0500 (CDT)
From: "Conrad J. Sabatier" <con...@cox.net>
Subject: Re: "Next Generation" kernel configuration?
To: "M. Warner Losh" <i...@bsdimp.com>
Cc: freebsd...@freebsd.org
Message-ID: <XFMail.2004072...@cox.net>
Content-Type: text/plain; charset=us-ascii
On 21-Jul-2004 M. Warner Losh wrote:
> In message:
> <1090393301.2...@wstaylorm.dand06.au.bytecraft.au.com>
> Murray Taylor <murray...@bytecraftsystems.com> writes:
>: As an initial starting point for 'preloading' any menubased kernel
>: configurator, could the file /var/run/dmesg.boot be usefully parsed
>: as
>: a list of 'this is what is actually installed in this box, what else
>: do
>: you want to add?" Of course any output developed on a run of the
>: configurator would/could/should be scanned as well to include
>: answers to
>: the question.."What did I include last time?"
>
> if devd could map, somehow, the pnp info into drivers to load, that
> would solve this problem.
>
> warner
Interesting ideas. Saving all this stuff in my "suggestion box". :-)
--
Conrad J. Sabatier <con...@cox.net> -- "In Unix veritas"
------------------------------
Message: 11
Date: Thu, 22 Jul 2004 06:49:21 -0500 (CDT)
From: "Conrad J. Sabatier" <con...@cox.net>
Subject: Re: "Next Generation" kernel configuration?
To: "Devon H. O'Dell" <dod...@sitetronics.com>
Cc: freebsd...@freebsd.org
Message-ID: <XFMail.2004072...@cox.net>
Content-Type: text/plain; charset=us-ascii
On 21-Jul-2004 Devon H. O'Dell wrote:
> I'm sure this will become another bikeshed, so I suggest whoever came
> up with the idea to put up or shut up. People are interested in
> solutions, not suggestions.
Agreed. And the original proponent of the idea was me. I just wanted
to see if there was any willingness to even consider something like
this before I went and did a lot of work for nothing.
Seems the general concensus is that most people are OK with the idea,
depending on the implementation.
I'll be quiet now until/unless I can actually come up with something.
:-)
--
Conrad J. Sabatier <con...@cox.net> -- "In Unix veritas"
------------------------------
Message: 12
Date: Wed, 21 Jul 2004 12:27:13 -0400
From: Joe Marcus Clarke <mar...@marcuscom.com>
Subject: Re: Getting a fully-qualified path from a PID
To: Dan Nelson <dne...@allantgroup.com>
Cc: hac...@freebsd.org
Message-ID: <1090427233.2...@shumai.marcuscom.com>
Content-Type: text/plain; charset="us-ascii"
On Wed, 2004-07-21 at 11:12, Dan Nelson wrote:
> In the last episode (Jul 20), Joe Marcus Clarke said:
> > What is the canonical way for a userland application to get the
> > fully-qualified path of an executable from its running PID? I know I
> > can do a readlink(2) on /proc/pid/file, but procfs is deprecated on
> > 5.X, correct? Is there a more appropriate way to do this? Thanks.
>
> realpath(argv[0]) works for commands not run from $PATH. Commands found
> through a PATH earch will just have the basename in argv[0] so you
> would have to check each PATH element until you found it. Note that
> /proc/pid/file won't work if vn_fullpath() fails (say the orignal file
> has been unlinked, or the filename has expired from the kernel's
> cache).
>
> If you are examining another process, you can use the kvm_getargv() and
> kvm_getenvv() functions to fetch argv[0] and PATH out of the target
> process.
Okay, I was thinking about that. What I was specifically interested in
was processes spawned from $PATH, so realpath isn't going to be much
good to me there. I didn't know if there was a better way than getting
the environ+argv with kvm, then searching each path element. Thanks for
the clarification.
Joe
--
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040721/3ed7163c/attachment-0001.bin
------------------------------
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
End of freebsd-hackers Digest, Vol 70, Issue 4
**********************************************