freebsd-hackers Digest, Vol 70, Issue 3
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: disk recovery help (Charles Sprickman)
2. xpt_schedule() and start interface context question.
(Joseph M Link)
3. Re: disk recovery help (Charles Sprickman)
4. FreeBSD 5.2 and ACPI (bsd hack)
5. How to clean out old files after 'make world'? (Stas D.Myasnikov)
6. Re: How to clean out old files after 'make world'?
(Garance A Drosihn)
7. Re: How to clean out old files after 'make world'? (Freddie Cash)
8. Re: How to clean out old files after 'make world'?
(Stas D.Myasnikov)
9. "Next Generation" kernel configuration? (Conrad J. Sabatier)
10. Re: "Next Generation" kernel configuration? (Brooks Davis)
11. Re: "Next Generation" kernel configuration? (Conrad J. Sabatier)
12. Re: "Next Generation" kernel configuration? (Max Laier)
13. Re: "Next Generation" kernel configuration? (Conrad J. Sabatier)
14. Re: "Next Generation" kernel configuration? (Conrad J. Sabatier)
15. Re: "Next Generation" kernel configuration? (Murray Taylor)
16. Getting a fully-qualified path from a PID (Joe Marcus Clarke)
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Jul 2004 14:01:06 -0400 (EDT)
From: Charles Sprickman <sp...@fasttrackmonkey.com>
Subject: Re: disk recovery help
To: Peter Jeremy <Peter...@optushome.com.au>
Cc: freebsd...@freebsd.org
Message-ID: <2004072013...@toad.nat.fasttrackmonkey.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
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 - a 'build' utility presumably
> writes known data to the array but logically it would do so
> sequentially. The only thing I can think of is that the controller
> had a significant amount of cached data - which has been wiped, rather
> than written back to the disk.
This is one case where I'd like to see a "Are you sure (y/n)?" prompt. In
the future, I'm sticking with the adaptec BIOS to do a drive
replace/rebuild. Adaptec's raidutil is just a bit too easy to shoot
yourself in the foot with. I have a call in to adaptec about this, they
are having a hard time telling me just what the "build" (not "rebuild")
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.
> If you haven't run newfs and have the correct disklabel, the disk
> should be in a reasonably sane state. Have you tried running something
> like ports/sysutils/scan_ffs over the disk (or your copy of it)?
I don't have the actual disk; we're very short on any sort of spare
hardware so we had to newfs the partition in question and start over. I
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. 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.
> Have you tried dumping vn0c?
I could try that, but I'd have to find myself another 26GB of space
somewhere.
Thanks!
Charles
> --
> Peter Jeremy
>
------------------------------
Message: 2
Date: Tue, 20 Jul 2004 13:06:24 -0500
From: Joseph M Link <fre...@joelink.net>
Subject: xpt_schedule() and start interface context question.
To: freebsd...@freebsd.org
Message-ID: <40FD5F20...@joelink.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Hello,
I have been looking at the targ driver written by Nate Lawson and Justin
Gibbs. I am seeing some access of user memory outside of what is
obviously user context (the call to copyin and cam_periph_mapmem() by
way of the targstart() interface). I am wondering how xpt_schedule()
works and if they are leveraging something there. Specifically, does a
call to a periph's start() function always get called in the same
context as the caller of xpt_schedule() (which happens to always be user
context in the targ driver)?
In looking at the code for xpt_schedule(), it definitely seems that that
is possible, but it also seems possible that if the device has no
resources available, the start() call is queued and delayed. If the
latter case is actually possible with the targ driver, then what context
is the targstart() called in? if it's not the user's context, that
would make the calls to copyin() and cam_periph_mapmem() behave
incorrectly, right?
Thanks,
Joe
------------------------------
Message: 3
Date: Tue, 20 Jul 2004 14:05:25 -0400 (EDT)
From: Charles Sprickman <sp...@fasttrackmonkey.com>
Subject: Re: disk recovery help
To: Eitarou Kamo <e-k...@trio.plala.or.jp>
Cc: freebsd...@freebsd.org
Message-ID: <2004072014...@toad.nat.fasttrackmonkey.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 20 Jul 2004, Eitarou Kamo wrote:
> >Here's what fsck says:
> >
> >root@skunkworks[/mnt/tmp/vpopmail/domains]# fsck /dev/vn0c ** /dev/vn0c
> >BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST
> >ALTERNATE
> >ioctl (GCINFO): Invalid argument
> >fsck: /dev/vn0c: can't read disk label
> >
> You'd like to do like? :
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-virtual.html
Yes, that allows me to mount the filesystem (but it is still "dirty",
which leads to the occasional panic).
Looking at that first message, fsck is telling me that it sees the
superblock and a superblock backup and that they do not agree. I know
when you newfs a filesystem there seem to be a ton of superblock backups.
How do I find out where they are and compare them? Meaning, if the main
one and first backup disagree, but three others all agree can I assume
they are probably right?
> If you'd like to restore dd.img to /dev/da1s1h normally you should
> use dd command directly. dd.img is not a data but just a image.
> So you need not create any file system.
That's what I thought, and that's what I originally tried to do, but after
fdisk'ing and labeling the spare drive to match the original label, dd was
refusing to write to the /dev/ad3s1h device, claiming it was "read only"
(I was root).
Thanks,
Charles
> FYI:
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks.html
>
> Eitarou
>
> --
>
>
> ***********************
> Eitarou Kamo
>
> Tel. +81 75 7035997
> Fax +81 75 7035997
> VoIP 050 10585997(domestic only)
> e-mail e-k...@trio.plala.or.jp
>
> For business:
> Feel free to mail me(above), please.
>
> Donation http://www.PayPal.Com
>
> GPG FingerPrint:
> 032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895
> ************************************************************************
>
>
>
>
>
>
------------------------------
Message: 4
Date: Tue, 20 Jul 2004 11:13:29 -0700 (PDT)
From: bsd hack <time_t...@yahoo.com>
Subject: FreeBSD 5.2 and ACPI
To: freebsd...@freebsd.org
Message-ID: <2004072018132...@web21507.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Hi,
I am building a custom kernel with FreeBSD 5.2... I need to disable ACPI (otherwise the system fails to recognize the disk!!)
... so is it fine if I just do a make and then a make install of the new kernel and then add hint.acpi.0.disabled to /boot/loader.conf ? or is anything to be done before doin a make and a make install?
any help will be appreciated.
Thank you.
HKR
---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!From owner-free...@FreeBSD.ORG Tue Jul 20 18:18:50 2004
Return-Path: <owner-free...@FreeBSD.ORG>
Delivered-To: freebsd...@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id A129916A4CE
for <freebsd...@freebsd.org>;
Tue, 20 Jul 2004 18:18:50 +0000 (GMT)
Received: from 194-185-53-242.f5.ngi.it (194-185-53-242.f5.ngi.it
[194.185.53.242])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8FC8843D60
for <freebsd...@freebsd.org>;
Tue, 20 Jul 2004 18:18:49 +0000 (GMT)
(envelope-from ma...@remotelab.org)
Received: from vaio.lab (localhost. [127.0.0.1])i6KIIm1k084607;
Tue, 20 Jul 2004 20:18:48 +0200 (CEST)
(envelope-from ma...@remotelab.org)
Received: from vaio.lab (localhost.lab [127.0.0.1])
by vaio.lab (8.12.10/8.12.10) with ESMTP id i6KIIPVk003080;
Tue, 20 Jul 2004 20:18:25 +0200 (CEST)
(envelope-from ma...@vaio.lab)
Received: (from mark@localhost)
by vaio.lab (8.12.10/8.12.10/Submit) id i6KIIP6J003079;
Tue, 20 Jul 2004 20:18:25 +0200 (CEST)
(envelope-from mark)
Date: Tue, 20 Jul 2004 20:18:25 +0200
From: Marco Trentini <ma...@remotelab.org>
To: bsd hack <time_t...@yahoo.com>
Message-ID: <2004072018...@vaio.lab>
References: <2004072018132...@web21507.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2004072018132...@web21507.mail.yahoo.com>
X-Operating-System: FreeBSD vaio.lab 5.2.1-RELEASE-p9 i386
User-Agent: Mutt/1.5.6i
cc: freebsd...@freebsd.org
Subject: Re: FreeBSD 5.2 and ACPI
X-BeenThere: freebsd...@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hac...@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd...@freebsd.org>
List-Help: <mailto:freebsd-hac...@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hac...@freebsd.org?subject=subscribe>
On Tue, Jul 20, 2004 at 11:13:29AM -0700, bsd hack wrote:
> Hi,
> I am building a custom kernel with FreeBSD 5.2... I need to disable ACPI (otherwise the system fails to recognize the disk!!)
> ... so is it fine if I just do a make and then a make install of the new kernel and then add hint.acpi.0.disabled to /boot/loader.conf ? or is anything to be done before doin a make and a make install?
>
> any help will be appreciated.
Put
hint.acpi.0.disabled=1
in your loader.conf, then reboot and build your custom kernel.
--
Marco Trentini ma...@remotelab.org
http://www.remotelab.org/
------------------------------
Message: 5
Date: Tue, 20 Jul 2004 22:23:25 +0300
From: Stas D.Myasnikov <my...@tut.by>
Subject: How to clean out old files after 'make world'?
To: <freebsd...@freebsd.org>
Message-ID: <web-10...@tut.by>
Content-Type: text/plain; charset="KOI8-R"; format="flowed"
Hello!
While doing 'make world' I used make.conf with couple on 'NO_*=yes',
e.g. NO_KERBEROS=yes (I don't need Kerberos on my home computer). But
after rebuilding world and install I saw the old binaries, configs,
etc. of Kerberos and other parts of base that I didn't build. I had
thought that install script removes all unneeded files, but it don't.
How can I clean out this old binaries, configs, etc?.. Is there any
automatic way to do this?
Bye.
--
Добро пожаловать в реальный мир! Твой ответ системе -
http://www.july21.info
------------------------------
Message: 6
Date: Tue, 20 Jul 2004 15:44:33 -0400
From: Garance A Drosihn <dro...@rpi.edu>
Subject: Re: How to clean out old files after 'make world'?
To: "Stas D.Myasnikov" <my...@tut.by>, <freebsd...@freebsd.org>
Message-ID: <p0611041dbd2326373ea5@[128.113.24.47]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 10:23 PM +0300 7/20/04, Stas D.Myasnikov wrote:
>... I had thought that install script removes all unneeded files,
>but it don't. How can I clean out this old binaries, configs, etc?..
>Is there any automatic way to do this?
You can: make cleanworld
which does a fairly decent job of getting rid of all the old files
in your build area (e.g., in /usr/obj/usr/src).
However, I am not sure if you are asking for more than that.
--
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
------------------------------
Message: 7
Date: Tue, 20 Jul 2004 12:56:45 -0700 (PDT)
From: "Freddie Cash" <fcas...@sd73.bc.ca>
Subject: Re: How to clean out old files after 'make world'?
To: hac...@freebsd.org
Message-ID: <1784.192.168.0.85....@192.168.0.85>
Content-Type: text/plain;charset=iso-8859-1
> At 10:23 PM +0300 7/20/04, Stas D.Myasnikov wrote:
>>... I had thought that install script removes all unneeded files,
>>but it don't. How can I clean out this old binaries, configs, etc?..
>>Is there any automatic way to do this?
> You can: make cleanworld
> which does a fairly decent job of getting rid of all the old files
> in your build area (e.g., in /usr/obj/usr/src).
That only cleans out the /usr/obj directory tree. It doesn't remove
any files from anywhere else in the system.
> However, I am not sure if you are asking for more than that.
He wants to install FreeBSD, edit make.conf and uncomment a bunch of
NO_* variables to prevent them from being built/install during a world
build, and wants to have a way to remove the existing files from /bin,
/sbin, /usr/bin, etc.
Check the How-To forum at http://www.bsdforums.org/forums/ One of the
members there posted a set of scripts that will parse the NO_*
variables in make.conf, and remove any and all files associated with
those subsystems from an installed system.
The end result is the same as building a custom release and
reinstalling using that release to only get the bits you want, but
without all the hassle of building a custom release. :)
--
Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech.
School District 73 (250) 377-HELP [377-4357]
fcas...@sd73.bc.ca
------------------------------
Message: 8
Date: Tue, 20 Jul 2004 23:19:54 +0300
From: Stas D.Myasnikov <my...@tut.by>
Subject: Re: How to clean out old files after 'make world'?
To: fcas...@sd73.bc.ca
Cc: freebsd...@freebsd.org
Message-ID: <web-10...@tut.by>
Content-Type: text/plain; charset="KOI8-R"; format="flowed"
Tue, 20 Jul 2004 12:56:45 -0700 (PDT), "Freddie Cash"
<fcas...@sd73.bc.ca> wrote:
>The end result is the same as building a custom release and
>reinstalling using that release to only get the bits you want, but
>without all the hassle of building a custom release. :)
Thanx! It's exactly what I want!
--
Добро пожаловать в реальный мир! Твой ответ системе -
http://www.july21.info
------------------------------
Message: 9
Date: Tue, 20 Jul 2004 19:39:31 -0500 (CDT)
From: "Conrad J. Sabatier" <con...@cox.net>
Subject: "Next Generation" kernel configuration?
To: freebsd...@freebsd.org
Cc: freebsd...@freebsd.org
Message-ID: <XFMail.2004072...@cox.net>
Content-Type: text/plain; charset=us-ascii
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.
Ideally, such a tool would be capable of automatically adapting itself
to handle and present as choices, in an orderly and logical fashion,
whatever devices, options, etc. were currently available, as defined by
the files in /sys/conf et al.
The major hurdle to overcome, it appears to me, is that the scheme
currently employed to describe the available devices, options, etc.
does not lend itself very easily at all to any kind of automatic
parsing or other manipulations. Determining dependencies between
components programmatically, for one thing, seems well near impossible.
The NOTES files, in their current form, make even finding the comment
associated with a particular option or device extremely difficult, if
not impossible.
Has this ever come up for discussion before? Now that we have rcNG,
with its explicit declarations of dependencies, has any thought been
given to doing something similar with kernel configuration files?
Something still human-readable, yet more orderly and systematic, easier
for a machine to interpret, present and verify?
A dependable tool offering a menu-driven means of configuring the
kernel, ensuring proper config file syntax, dependency handling,
prevention of incompatible options, etc. -- as well as online
documentation, advice, suggestions and warnings, plus perhaps a nice
set of default selections -- would be a very nice addition to the
system. But to bring it about, obviously a major reworking of the
current system of kernel configuration files would be required.
Thoughts?
--
Conrad J. Sabatier <con...@cox.net> -- "In Unix veritas"
------------------------------
Message: 10
Date: Tue, 20 Jul 2004 18:03:42 -0700
From: Brooks Davis <bro...@one-eyed-alien.net>
Subject: Re: "Next Generation" kernel configuration?
To: "Conrad J. Sabatier" <con...@cox.net>
Cc: freebsd...@freebsd.org
Message-ID: <2004072101...@Odin.AC.HMC.Edu>
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.
>
> Ideally, such a tool would be capable of automatically adapting itself
> to handle and present as choices, in an orderly and logical fashion,
> whatever devices, options, etc. were currently available, as defined by
> the files in /sys/conf et al.
>
> The major hurdle to overcome, it appears to me, is that the scheme
> currently employed to describe the available devices, options, etc.
> does not lend itself very easily at all to any kind of automatic
> parsing or other manipulations. Determining dependencies between
> components programmatically, for one thing, seems well near impossible.
> The NOTES files, in their current form, make even finding the comment
> associated with a particular option or device extremely difficult, if
> not impossible.
>
> Has this ever come up for discussion before? Now that we have rcNG,
> with its explicit declarations of dependencies, has any thought been
> given to doing something similar with kernel configuration files?
> Something still human-readable, yet more orderly and systematic, easier
> for a machine to interpret, present and verify?
There have been previous discussions. They should be visiable in the
archives if you can find the magic search strings.
> A dependable tool offering a menu-driven means of configuring the
> kernel, ensuring proper config file syntax, dependency handling,
> prevention of incompatible options, etc. -- as well as online
> documentation, advice, suggestions and warnings, plus perhaps a nice
> set of default selections -- would be a very nice addition to the
> system. But to bring it about, obviously a major reworking of the
> current system of kernel configuration files would be required.
You can have my simple flat file kernel config when you pry it from my
cold, dead hands and I know a number of other develoeprs share this
viewpoint. All my experiences with the linux visual kernel config tool
have been annoying and I've got friends with more expierence with it
that have much less kind things to say.
That said, so long as it doesn't impose too much developer burden,
an improved set of backend files that did a better job of handling
dependencies and knew which options where relevent given the configured
set of devices could be useful.
There is a valid question of what a depenency means. For instance, you
can't really have IP networking without lo(4) (there's a null pointer
derefrence if you try), but since you can load it as a module, should
you have to compile it in?
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040720/36fe51a6/attachment-0001.bin
------------------------------
Message: 11
Date: Tue, 20 Jul 2004 20:22:56 -0500 (CDT)
From: "Conrad J. Sabatier" <con...@cox.net>
Subject: Re: "Next Generation" kernel configuration?
To: freebsd...@freebsd.org
Cc: freebsd...@freebsd.org
Message-ID: <XFMail.2004072...@cox.net>
Content-Type: text/plain; charset=us-ascii
On 21-Jul-2004 Conrad J. Sabatier wrote:
[snip]
> Has this ever come up for discussion before? Now that we have rcNG,
> with its explicit declarations of dependencies, has any thought been
> given to doing something similar with kernel configuration files?
> Something still human-readable, yet more orderly and systematic,
> easier for a machine to interpret, present and verify?
Just a note of clarification here: the use of the term "kernel
configuration files" in the above paragraph refers to the entire set of
files residing under /sys/conf and friends, not the user's kernel
config.
Just wanted to make sure. :-)
--
Conrad J. Sabatier <con...@cox.net> -- "In Unix veritas"
------------------------------
Message: 12
Date: Wed, 21 Jul 2004 03:27:22 +0200
From: Max Laier <m...@love2party.net>
Subject: Re: "Next Generation" kernel configuration?
To: freebsd...@freebsd.org
Cc: freebsd...@freebsd.org
Message-ID: <20040721032...@love2party.net>
Content-Type: text/plain; charset="iso-8859-1"
On Wednesday 21 July 2004 03:03, Brooks Davis 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.
> >
> > Ideally, such a tool would be capable of automatically adapting itself
> > to handle and present as choices, in an orderly and logical fashion,
> > whatever devices, options, etc. were currently available, as defined by
> > the files in /sys/conf et al.
> >
> > The major hurdle to overcome, it appears to me, is that the scheme
> > currently employed to describe the available devices, options, etc.
> > does not lend itself very easily at all to any kind of automatic
> > parsing or other manipulations. Determining dependencies between
> > components programmatically, for one thing, seems well near impossible.
> > The NOTES files, in their current form, make even finding the comment
> > associated with a particular option or device extremely difficult, if
> > not impossible.
> >
> > Has this ever come up for discussion before? Now that we have rcNG,
> > with its explicit declarations of dependencies, has any thought been
> > given to doing something similar with kernel configuration files?
> > Something still human-readable, yet more orderly and systematic, easier
> > for a machine to interpret, present and verify?
>
> There have been previous discussions. They should be visiable in the
> archives if you can find the magic search strings.
>
> > A dependable tool offering a menu-driven means of configuring the
> > kernel, ensuring proper config file syntax, dependency handling,
> > prevention of incompatible options, etc. -- as well as online
> > documentation, advice, suggestions and warnings, plus perhaps a nice
> > set of default selections -- would be a very nice addition to the
> > system. But to bring it about, obviously a major reworking of the
> > current system of kernel configuration files would be required.
>
> You can have my simple flat file kernel config when you pry it from my
> cold, dead hands and I know a number of other develoeprs share this
> viewpoint. All my experiences with the linux visual kernel config tool
> have been annoying and I've got friends with more expierence with it
> that have much less kind things to say.
Add me to the list. And this realates to sys/conf/* as well (respondig to the
re-reply). Especially developers prefer *clean*, *simple* config files and I
(personally) would really really hate to twiddle with some insane XML just to
add something to the build!
> That said, so long as it doesn't impose too much developer burden,
> an improved set of backend files that did a better job of handling
> dependencies and knew which options where relevent given the configured
> set of devices could be useful.
http://www.freebsd.org/releases/5.3R/todo.html has a "Desired features"-item
saying: "Revised kld build infrastructure", which will pretty much interfere
with this. You might want to contact with the current owner (peter@) and hear
what he has to say. Other than that, I'd welcome a somewhat enriched config
environment as long as it is done reasonable and makes the job easier! And
please: NO XML!
> There is a valid question of what a depenency means. For instance, you
> can't really have IP networking without lo(4) (there's a null pointer
> derefrence if you try), but since you can load it as a module, should
> you have to compile it in?
There should be levels of dependencies ... i.e. the TBD config-tool would
(strongly) suggest that you build-in lo(4) into an "options INET" kernel, but
should not stop you to do else.
--
/"\ Best regards, | mla...@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040721/0aa5e7ad/attachment-0001.bin
------------------------------
Message: 13
Date: Tue, 20 Jul 2004 20:37:26 -0500 (CDT)
From: "Conrad J. Sabatier" <con...@cox.net>
Subject: Re: "Next Generation" kernel configuration?
To: Brooks Davis <bro...@one-eyed-alien.net>
Cc: freebsd...@freebsd.org
Message-ID: <XFMail.2004072...@cox.net>
Content-Type: text/plain; charset=us-ascii
On 21-Jul-2004 Brooks Davis wrote:
> You can have my simple flat file kernel config when you pry it from
> my cold, dead hands and I know a number of other develoeprs share
> this viewpoint. All my experiences with the linux visual kernel
> config tool have been annoying and I've got friends with more
> expierence with it that have much less kind things to say.
Well, the idea is not to replace the current use of a single, flat
kernel config file, only to ease its creation. The end result would
be essentially the same, although with a slightly different arrangement
of items, of course.
> That said, so long as it doesn't impose too much developer burden,
> an improved set of backend files that did a better job of handling
> dependencies and knew which options where relevent given the
> configured set of devices could be useful.
Yes, I think it's an interesting area for exploration.
> There is a valid question of what a depenency means. For instance,
> you can't really have IP networking without lo(4) (there's a null
> pointer derefrence if you try), but since you can load it as a
> module, should you have to compile it in?
Hmm, good point. This will obviously require some careful thinking.
As I told Julian Elischer just now in another (private) reply, I don't
have even the first sketches of such a reorganization on the drawing
board. I was curious to see how such an idea would be received first.
If there's a lot of resistance (which I could certainly understand), I
won't even bother. But if there's an interest...I'd certainly be
willing to invest some time in it and see what I could cook up.
So far, no one's yelling "blasphemer!" or anything. But then it's
still early. We'll see. :-)
--
Conrad J. Sabatier <con...@cox.net> -- "In Unix veritas"
------------------------------
Message: 14
Date: Tue, 20 Jul 2004 20:53:41 -0500 (CDT)
From: "Conrad J. Sabatier" <con...@cox.net>
Subject: Re: "Next Generation" kernel configuration?
To: Max Laier <m...@love2party.net>
Cc: freebsd...@freebsd.org
Message-ID: <XFMail.2004072...@cox.net>
Content-Type: text/plain; charset=us-ascii
On 21-Jul-2004 Max Laier wrote:
> On Wednesday 21 July 2004 03:03, Brooks Davis wrote:
>> On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote:
[snip]
>> > A dependable tool offering a menu-driven means of configuring the
>> > kernel, ensuring proper config file syntax, dependency handling,
>> > prevention of incompatible options, etc. -- as well as online
>> > documentation, advice, suggestions and warnings, plus perhaps a
>> > nice set of default selections -- would be a very nice addition to
>> > the system. But to bring it about, obviously a major reworking of
>> > the current system of kernel configuration files would be required.
>>
>> You can have my simple flat file kernel config when you pry it from
>> my cold, dead hands and I know a number of other develoeprs share
>> this viewpoint. All my experiences with the linux visual kernel
>> config tool have been annoying and I've got friends with more
>> expierence with it that have much less kind things to say.
>
> Add me to the list. And this realates to sys/conf/* as well
> (respondig to the re-reply). Especially developers prefer *clean*,
> *simple* config files and I (personally) would really really hate to
> twiddle with some insane XML just to add something to the build!
Oh, agreed, definitely. Wasn't even thinking XML (yuck!). :-)
Basically, I'm just thinking of a layout which, in the simplest,
cleanest manner possible, would allow a "make config"-like tool to
extract the information it needed, so options could be presented to
the user along with their descriptions, if so desired. I don't have a
clear-cut idea just yet of how this might be done, to be honest. :-)
>> That said, so long as it doesn't impose too much developer burden,
>> an improved set of backend files that did a better job of handling
>> dependencies and knew which options where relevent given the
>> configured set of devices could be useful.
>
> http://www.freebsd.org/releases/5.3R/todo.html has a "Desired
> features"-item saying: "Revised kld build infrastructure", which
> will pretty much interfere with this. You might want to contact with
> the current owner (peter@) and hear what he has to say.
Thanks for the pointer. I'll check into that.
> Other than that, I'd welcome a somewhat enriched config
> environment as long as it is done reasonable and makes the job
> easier! And please: NO XML!
Cool. And not to worry. No XML. :-)
>> There is a valid question of what a depenency means. For instance,
>> you can't really have IP networking without lo(4) (there's a null
>> pointer derefrence if you try), but since you can load it as a
>> module, should you have to compile it in?
>
> There should be levels of dependencies ... i.e. the TBD config-tool
> would (strongly) suggest that you build-in lo(4) into an "options
> INET" kernel, but should not stop you to do else.
Exactly. That's the sort of thing I had in mind.
I realize this is a fairly large undertaking, and hearing that others
have already made attempts but have yet to produce anything makes me a
little uncertain about it all, but I do think it's something worth
exploring. And it'll keep me off the streets and out of trouble for a
good while, too. :-)
If I manage to come up with anything reasonable, you'll hear about it
here.
Incidentally, is anyone else's mail to freebsd-config bouncing?
=======BOUNCE MESSAGE======
This is the Postfix program at host hub.freebsd.org.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
<freebsd...@freebsd.org>: Command died with status 1:
"/usr/local/mailman/mail/mailman post freebsd-config". Command
output: post
script, list not found: freebsd-config
--
Conrad J. Sabatier <con...@cox.net> -- "In Unix veritas"
------------------------------
Message: 15
Date: Wed, 21 Jul 2004 17:01:41 +1000
From: Murray Taylor <murray...@bytecraftsystems.com>
Subject: Re: "Next Generation" kernel configuration?
To: con...@cox.net
Cc: Max Laier <m...@love2party.net>
Message-ID:
<1090393301.2...@wstaylorm.dand06.au.bytecraft.au.com>
Content-Type: text/plain
On Wed, 2004-07-21 at 11:53, Conrad J. Sabatier wrote:
> On 21-Jul-2004 Max Laier wrote:
> > On Wednesday 21 July 2004 03:03, Brooks Davis wrote:
> >> On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote:
> [snip]
> >> > A dependable tool offering a menu-driven means of configuring the
> >> > kernel, ensuring proper config file syntax, dependency handling,
> >> > prevention of incompatible options, etc. -- as well as online
> >> > documentation, advice, suggestions and warnings, plus perhaps a
> >> > nice set of default selections -- would be a very nice addition to
> >> > the system. But to bring it about, obviously a major reworking of
> >> > the current system of kernel configuration files would be required.
> >>
> >> You can have my simple flat file kernel config when you pry it from
> >> my cold, dead hands and I know a number of other develoeprs share
> >> this viewpoint. All my experiences with the linux visual kernel
> >> config tool have been annoying and I've got friends with more
> >> expierence with it that have much less kind things to say.
> >
> > Add me to the list. And this realates to sys/conf/* as well
> > (respondig to the re-reply). Especially developers prefer *clean*,
> > *simple* config files and I (personally) would really really hate to
> > twiddle with some insane XML just to add something to the build!
>
> Oh, agreed, definitely. Wasn't even thinking XML (yuck!). :-)
>
> Basically, I'm just thinking of a layout which, in the simplest,
> cleanest manner possible, would allow a "make config"-like tool to
> extract the information it needed, so options could be presented to
> the user along with their descriptions, if so desired. I don't have a
> clear-cut idea just yet of how this might be done, to be honest. :-)
>
> >> That said, so long as it doesn't impose too much developer burden,
> >> an improved set of backend files that did a better job of handling
> >> dependencies and knew which options where relevent given the
> >> configured set of devices could be useful.
> >
> > http://www.freebsd.org/releases/5.3R/todo.html has a "Desired
> > features"-item saying: "Revised kld build infrastructure", which
> > will pretty much interfere with this. You might want to contact with
> > the current owner (peter@) and hear what he has to say.
>
> Thanks for the pointer. I'll check into that.
>
> > Other than that, I'd welcome a somewhat enriched config
> > environment as long as it is done reasonable and makes the job
> > easier! And please: NO XML!
>
> Cool. And not to worry. No XML. :-)
>
> >> There is a valid question of what a depenency means. For instance,
> >> you can't really have IP networking without lo(4) (there's a null
> >> pointer derefrence if you try), but since you can load it as a
> >> module, should you have to compile it in?
> >
> > There should be levels of dependencies ... i.e. the TBD config-tool
> > would (strongly) suggest that you build-in lo(4) into an "options
> > INET" kernel, but should not stop you to do else.
>
> Exactly. That's the sort of thing I had in mind.
>
> I realize this is a fairly large undertaking, and hearing that others
> have already made attempts but have yet to produce anything makes me a
> little uncertain about it all, but I do think it's something worth
> exploring. And it'll keep me off the streets and out of trouble for a
> good while, too. :-)
>
> If I manage to come up with anything reasonable, you'll hear about it
> here.
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?"
0.02c
--
Murray Taylor
Special Projects Engineer
---------------------------------
Bytecraft Systems & Entertainment
P: +61 3 8710 2555
F: +61 3 8710 2599
D: +61 3 9238 4275
M: +61 417 319 256
E: murray...@bytecraftsystems.com
or visit us on the web
http://www.bytecraftsystems.com
http://www.bytecraftentertainment.com
---------------------------------------------------------------
The information transmitted in this e-mail is for the exclusive
use of the intended addressee and may contain confidential
and/or privileged material. Any review, re-transmission,
dissemination or other use of it, or the taking of any action
in reliance upon this information by persons and/or entities
other than the intended recipient is prohibited. If you
received this in error, please inform the sender and/or
addressee immediately and delete the material.
E-mails may not be secure, may contain computer viruses and
may be corrupted in transmission. Please carefully check this
e-mail (and any attachment) accordingly. No warranties are
given and no liability is accepted for any loss or damage
caused by such matters.
---------------------------------------------------------------
****************************************************************
This Email has been scanned for Viruses by MailMarshal.
****************************************************************
------------------------------
Message: 16
Date: Tue, 20 Jul 2004 22:47:47 -0400
From: Joe Marcus Clarke <mar...@marcuscom.com>
Subject: Getting a fully-qualified path from a PID
To: hac...@freebsd.org
Message-ID: <1090378066.90...@shumai.marcuscom.com>
Content-Type: text/plain; charset="us-ascii"
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.
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/20040720/0950f54f/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 3
**********************************************