Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-hackers-digest V5 #751

4 views

Skip to first unread message

owner-freebsd-...@freebsd.org

unread,

Mar 22, 2003, 1:37:28 AM3/22/03

freebsd-hackers-digest Friday, March 21 2003 Volume 05 : Number 751

In this issue:
Re: generalized mergemaster(8)
Re: generalized mergemaster(8)
Re: generalized mergemaster(8)
Re: generalized mergemaster(8)
bug in subr_bus.c?
Re: bug in subr_bus.c?
Build options for kernel modules
Re: Build options for kernel modules
Re: Build options for kernel modules
Re: generalized mergemaster(8)
Re: Build options for kernel modules
Re: Build options for kernel modules
Re: Build options for kernel modules
แจกฟรี ! หนังสือคู่มือคนเคยจน สำหรับผู้สนใจ....
Re: Build options for kernel modules
แจกฟรี ! หนังสือคู่มือคนเคยจน สำหรับผู้สนใจ....
Re: Build options for kernel modules
ld.so and hard links
Re: Build options for kernel modules
Re: generalized mergemaster(8)
Re: CerbNG 1.0-RC1 is now avaliable.
Re: generalized mergemaster(8)
Lots of kernel core dumps
Re: CerbNG 1.0-RC1 is now avaliable.
Re: ld.so and hard links
Re: Lots of kernel core dumps
Re: Lots of kernel core dumps
Re: Lots of kernel core dumps
Re: Lots of kernel core dumps
Re: ld.so and hard links
Re: misc/41772: can't disable keybell [PATCH]

----------------------------------------------------------------------

Date: Fri, 21 Mar 2003 00:27:38 -0600
From: "Brandon D. Valentine" <bra...@dvalentine.com>
Subject: Re: generalized mergemaster(8)

[ I meant to Cc dougb, not 'doubg' on this. Doh. ]

On Thu, Mar 20, 2003 at 10:15:48PM -0600, Brandon D. Valentine wrote:
> I have encountered a situation in which it would be extremely handy to
> have a generalized version of mergemaster(8) which is less specific to
> the task of merging /etc. I need to recursively merge two directories
> of source files in which I wish to preserve some original files, install
> some replacement files outright, and only actually go to the trouble of
> sdiff(1)ing those files that from the preview udiff look like they are
> need of a merge. Has anyone already done the work of generalizing
> mergemaster to this more general task? And if not, is there interest in
> this? If nobody has done it I'm probably about to. My inclination is
> to extend the existing mergemaster script to support this general
> functionality while maintaining support for the specific case of an /etc
> merge. mergemaster(8) is already fairly applicable to this task but it
> currently makes some assumptions about what your $Id$ looks like and
> that you will in fact be running make(1) somewhere to generate your
> temproot.
>
> Thoughts?
>
> Brandon D. Valentine
> --
> bra...@dvalentine.com http://www.geekpunk.net
> Pseudo-Random Googlism: valentine is her husband
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message

Brandon D. Valentine
- --
bra...@dvalentine.com http://www.geekpunk.net
Pseudo-Random Googlism: brandon is a rare football player with great hands
and speed

------------------------------

Date: Fri, 21 Mar 2003 19:21:08 +1100
From: Peter Jeremy <peter...@optushome.com.au>
Subject: Re: generalized mergemaster(8)

Have you considered emacs ediff-directories? It might be better suited
than mergemaster for handling arbitrary directories.

Peter

------------------------------

Date: Fri, 21 Mar 2003 03:02:58 -0600
From: "Brandon D. Valentine" <bra...@dvalentine.com>
Subject: Re: generalized mergemaster(8)

[ This email edited in vim. ]

On Fri, Mar 21, 2003 at 07:21:08PM +1100, Peter Jeremy wrote:
>
> Have you considered emacs ediff-directories? It might be better suited
> than mergemaster for handling arbitrary directories.

No, I have not considered it. ;-)

As for mergemaster, it just about works for arbitrary directories. I've
been playing around with it locally and there's not much effort needed
to generalize it. The only challenge is maintaining POLA wrt people
using mergemaster for its intended purpose, updating /etc
post-installworld, without having the general functionality seem like a
hack.

I've got it working well enough for what I needed it for, but if there
is interest I will cleanup the patches so they're POLA-safe and post
them here.

Brandon D. Valentine
- --
bra...@dvalentine.com http://www.geekpunk.net
Pseudo-Random Googlism: valentine is the most precocious foal i have ever met

------------------------------

Date: Fri, 21 Mar 2003 06:40:26 -0700 (MST)
From: "M. Warner Losh" <i...@bsdimp.com>
Subject: Re: generalized mergemaster(8)

In message: <2003032108...@cirb503493.alcatel.com.au>
Peter Jeremy <peter...@optushome.com.au> writes:
: Have you considered emacs ediff-directories? It might be better suited
: than mergemaster for handling arbitrary directories.

NetBSD also has usr.sbin/etcupdate, which appears to be a redone
mergemaster which seems to a little better.

Personally, I wish that there was a set of scripts that did the
following:

(1) gather all the files together that its going to update.
(2) cvs import them into a repository on a vendor branch.
(3.a) before the update, it would take recent changes and
commit them to the head of this repo.
(b) It would then cvs import the latest from a FreeBSD
source tree onto the vendor branch.
(c) it would run cvs update -j old -j new
(d) cvs commit after resolving 'C'
(e) install those that differ unconditionally
(f) run the scripts that mergemaster runs now if the magic
files are updated.

But that's quite a bit different than mergemaster, and a lot more
overhead to setup unless the scripts are very smart...

Warner

------------------------------

Date: Fri, 21 Mar 2003 21:17:18 +0700 (ICT)
From: John-Mark Gurney <gurn...@resnet.uoregon.edu>
Subject: bug in subr_bus.c?

Hello,

It's been a while since I've been doing FreeBSD work, but I was recently
working on a device driver for the Pinicle Micro DC10+ (Zoran chip) video
en/decoder board and was making full use of the newbus system.

I've been doing my devel work on 5.0-R (I'm in Thailand right now so I
don't have my normal devel environment) and doing it all on KLD to help
speed up devel.

Right now the problem I have is on kldunload, devclass_delete_driver gets
called and calls the detach routine for all associated devices. This is a
slight problem since device_detach doesn't know anything about the
children, and if you look at device_delete_child, it deletes all the
children, and then calls detach.

So, the driver can:
a) delete it's own children, but if it gets removed via
device_delete_child, this work is already down for you.
b) let the bus code remove your children, but then if you're a kld,
your children won't be removed and you will cause a panic in devinfo and
other nasties since a device's parent won't exist anymore.

I believe that devclass_delete_driver should do a device_delete_child
instead of a simple detach, but then there is much code that is broken in
that it assumes that it needs to delete it's own children.

So, do we have the *_detach routine delete it's children or have the bus
code do it? If you look at sys/dev/iicbus/iicbb.c, in the detach routine
it delete's the iicbus child, but that would already be gone in the
delete_child case, but not in the simple detach case.

So, which is correct?

I'll fix this, but I need direction on which way to go. I think that
letting the bus code delete the children is better.

Comments?

btw, I will post some scripts to autoload kld debug symbols to my home
page (http://people.freebsd.org/~jmg/) soon.

John-Mark Gurney

------------------------------

Date: Fri, 21 Mar 2003 09:46:03 -0500 (EST)
From: "Matthew N. Dodd" <md...@FreeBSD.ORG>
Subject: Re: bug in subr_bus.c?

On Fri, 21 Mar 2003, John-Mark Gurney wrote:
> So, the driver can:
> a) delete it's own children, but if it gets removed via
> device_delete_child, this work is already down for you.

If you create children then you're going to be involved in removing them.

There are helper routines that simplify some operations but I don't
believe any changes to subr_bus.c are needed.

------------------------------

Date: Fri, 21 Mar 2003 18:32:17 +0300
From: Yar Tikhiy <y...@freebsd.org>
Subject: Build options for kernel modules

Hi there,

Excuse my stupid question, but I seem to have no time to do the
investigation by myself right now so I'd be glad to receive a brief
answer from someone who has the information.

As far as I can see, kernel modules should be built along with the
kernel for the only reason of keeping their mutual interfaces in
sync, has a source file defining such an interface changed. Is
there currently no way to go further and affect a kernel module's
built-in features with kernel config file options, besides modifying
makefiles in /sys/modules?

- --
Yar

------------------------------

Date: Fri, 21 Mar 2003 17:35:22 +0200
From: Ruslan Ermilov <r...@FreeBSD.ORG>
Subject: Re: Build options for kernel modules

- --GxcwvYAGnODwn7V8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote:
> Hi there,
>=20
> Excuse my stupid question, but I seem to have no time to do the
> investigation by myself right now so I'd be glad to receive a brief
> answer from someone who has the information.
>=20
> As far as I can see, kernel modules should be built along with the
> kernel for the only reason of keeping their mutual interfaces in
> sync, has a source file defining such an interface changed. Is
> there currently no way to go further and affect a kernel module's
> built-in features with kernel config file options, besides modifying
> makefiles in /sys/modules?
>=20
There is. It's called ``makeoptions''. It's passed to both
kernel and modules builds.

Cheers,
- --=20
Ruslan Ermilov Sysadmin and DBA,
r...@sunbay.com Sunbay Software AG,
r...@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine

http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age

- --GxcwvYAGnODwn7V8
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+ezE6Ukv4P6juNwoRAp+rAJ9VDor4fjSPT7BTOyMyFSXW5c2qzACggOEk
yuXajneqZ0ugZu1Exl1fRyQ=
=GjTa
- -----END PGP SIGNATURE-----

- --GxcwvYAGnODwn7V8--

------------------------------

Date: Fri, 21 Mar 2003 17:39:07 +0200
From: "Nikolay Y. Orlyuk" <nik...@asu.ntu-kpi.kiev.ua>
Subject: Re: Build options for kernel modules

On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote:
> Hi there,
>
> Excuse my stupid question, but I seem to have no time to do the
> investigation by myself right now so I'd be glad to receive a brief
> answer from someone who has the information.
>
> As far as I can see, kernel modules should be built along with the
> kernel for the only reason of keeping their mutual interfaces in
> sync, has a source file defining such an interface changed. Is
> there currently no way to go further and affect a kernel module's
> built-in features with kernel config file options, besides modifying
> makefiles in /sys/modules?
I think this isn't so. I have been already tried to compile some modules
without compiling kernel and this trye has successful result, but without
change options.
I think modules must be build with same or less imports and same or more export to be correct
for loading.
>

- --
With best wishes Nikolay
mail: nik...@asu.ntu-kpi.kiev.ua

------------------------------

Date: Fri, 21 Mar 2003 11:09:25 -0500
From: The Anarcat <ana...@anarcat.ath.cx>
Subject: Re: generalized mergemaster(8)

- --8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

What we need is a way to mark some package files as customizeable
files, or configuration files. The same way that some files are marked
DOC, but a bit better: it would need to be carried to the installed
package database.

This is again re-inventing the wheel since it is exactly how Debian's
apt-get system deals with configuration files. /etc files are part of
a package that, when upgraded, are checked for modification and the
user is offered the choice similar to mergemaster to install, merge,
or just delete.

We still need to write a generic tool to diff and merge. It's not so
hard to write. It would basically be a stripped down version of
mergemaster -s. I think such a tool would be really useful.

On Thu Mar 20, 2003 at 10:15:48PM -0600, Brandon D. Valentine wrote:
> I have encountered a situation in which it would be extremely handy to
> have a generalized version of mergemaster(8) which is less specific to
> the task of merging /etc. I need to recursively merge two directories
> of source files in which I wish to preserve some original files, install
> some replacement files outright, and only actually go to the trouble of
> sdiff(1)ing those files that from the preview udiff look like they are
> need of a merge. Has anyone already done the work of generalizing
> mergemaster to this more general task? And if not, is there interest in
> this? If nobody has done it I'm probably about to. My inclination is
> to extend the existing mergemaster script to support this general
> functionality while maintaining support for the specific case of an /etc
> merge. mergemaster(8) is already fairly applicable to this task but it
> currently makes some assumptions about what your $Id$ looks like and
> that you will in fact be running make(1) somewhere to generate your
> temproot.
>=20
> Thoughts?
>=20
> Brandon D. Valentine
> --=20
> bra...@dvalentine.com http://www.geekpun=
k.net
> Pseudo-Random Googlism: valentine is her husband
>=20
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>=20

- --=20
Advertisers, not governments, are the primary censors of media content=20
in the United States today.
- C. Edwin Baker
http://www.ad-mad.co.uk/quotes/freespeech.htm

- --8t9RHnE3ZwKMSgU+
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+ezk0ttcWHAnWiGcRAruvAKCG43EnbYgnlZiIpRblFQjJz1S4VwCgnO6f
ZW7u7kgPaXXuy0vQ2Ny/JXE=
=6t6M
- -----END PGP SIGNATURE-----

- --8t9RHnE3ZwKMSgU+--

------------------------------

Date: Fri, 21 Mar 2003 19:16:58 +0300
From: Yar Tikhiy <y...@freebsd.org>
Subject: Re: Build options for kernel modules

On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote:
> On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote:
> > Hi there,
> >
> > Excuse my stupid question, but I seem to have no time to do the
> > investigation by myself right now so I'd be glad to receive a brief
> > answer from someone who has the information.
> >
> > As far as I can see, kernel modules should be built along with the
> > kernel for the only reason of keeping their mutual interfaces in
> > sync, has a source file defining such an interface changed. Is
> > there currently no way to go further and affect a kernel module's
> > built-in features with kernel config file options, besides modifying
> > makefiles in /sys/modules?
> I think this isn't so. I have been already tried to compile some modules
> without compiling kernel and this trye has successful result, but without
> change options.
> I think modules must be build with same or less imports and same or more export to be correct
> for loading.

Yeah, it's all right to compile modules w/o the kernel, but that's
not exactly what I was asking about. My question was whether "option
FOO" lines from a kernel configuration file could influence modules.

- --
Yar

------------------------------

Date: Fri, 21 Mar 2003 11:25:01 -0500
From: The Anarcat <ana...@anarcat.ath.cx>
Subject: Re: Build options for kernel modules

- --KN5l+BnMqAQyZLvT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote:
> On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote:
> > On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote:
> > > Hi there,
> > >=20
> > > Excuse my stupid question, but I seem to have no time to do the
> > > investigation by myself right now so I'd be glad to receive a brief
> > > answer from someone who has the information.
> > >=20
> > > As far as I can see, kernel modules should be built along with the
> > > kernel for the only reason of keeping their mutual interfaces in
> > > sync, has a source file defining such an interface changed. Is
> > > there currently no way to go further and affect a kernel module's
> > > built-in features with kernel config file options, besides modifying
> > > makefiles in /sys/modules?
> > I think this isn't so. I have been already tried to compile some modules
> > without compiling kernel and this trye has successful result, but witho=
ut
> > change options.
> > I think modules must be build with same or less imports and same or mor=
e export to be correct
> > for loading.
>=20
> Yeah, it's all right to compile modules w/o the kernel, but that's
> not exactly what I was asking about. My question was whether "option
> FOO" lines from a kernel configuration file could influence modules.

I'm pretty sure they do. A great example is IPFIREWALL_* options: if
they don't influence the module, I think we have a problem. ;)

A.
- --=20
Advertisers, not governments, are the primary censors of media content=20
in the United States today.
- C. Edwin Baker
http://www.ad-mad.co.uk/quotes/freespeech.htm

- --KN5l+BnMqAQyZLvT
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+ezzdttcWHAnWiGcRAiSwAJ9VguTVLfAKTdLApBeNqYk2j2T6WACfbEeb
32scoLHMccJwCTkYViC2OMQ=
=GbHo
- -----END PGP SIGNATURE-----

- --KN5l+BnMqAQyZLvT--

------------------------------

Date: Fri, 21 Mar 2003 19:32:40 +0300
From: Yar Tikhiy <y...@FreeBSD.ORG>
Subject: Re: Build options for kernel modules

On Fri, Mar 21, 2003 at 05:35:22PM +0200, Ruslan Ermilov wrote:
> On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote:
> > Hi there,
> >
> > Excuse my stupid question, but I seem to have no time to do the
> > investigation by myself right now so I'd be glad to receive a brief
> > answer from someone who has the information.
> >
> > As far as I can see, kernel modules should be built along with the
> > kernel for the only reason of keeping their mutual interfaces in
> > sync, has a source file defining such an interface changed. Is
> > there currently no way to go further and affect a kernel module's
> > built-in features with kernel config file options, besides modifying
> > makefiles in /sys/modules?
> >
> There is. It's called ``makeoptions''. It's passed to both
> kernel and modules builds.

I beg your pardon, but "makeoptions" is just next to editing makefiles
in /sys/modules.
My dream was that specifying, e.g., "options IPFIREWALL_VERBOSE"
would result in building ipfw.ko inherently chatty :-)

BTW, Ruslan, let me ask you another question, as you've been recently
working at kern.mk files. Is it on purpose that the target
"kernel-cleandir" doesn't invoke "kernel-cleandepend"?
I've been sure that by common practice "cleandir" should remove
dependency files...

- --
Yar

------------------------------

Date: Fri, 21 Mar 2003 23:31:04 +0700 (GMT)
From: FreeB...@thaimail.com
Subject: แจกฟรี ! หนังสือคู่มือคนเคยจน สำหรับผู้สนใจ....

- --#MYBOUNDARY#
Content-Type: text/plain; charset=ansi
Content-Transfer-Encoding: 8bit

>>>>ทำงานที่ยากที่สุดก่อน >>>>
>>ผมยิ่งมีชีวิตอยู่นานเท่าไหร่ ผมยิ่งมั่นใจมากขึ้นเท่านั้น
>>ว่าความแตกต่างอันยิ่งใหญ่ระหว่างมนุษย์...
>>ระหว่าคนที่อ่อนแอและคนทีอำนาจ.......
>>ระหว่างคนที่ยิ่งใหญ่และคนที่ไม่สำคัญ ก็คือ
>>เรี่ยวแรงของ....ความตั้งใจแน่วแน่ที่ไม่อาจทำลายได้....
>>จุดประสงค์ที่เมื่อตั้งขึ้นแล้ว ถ้าไม่ตายก็ต้องชนะ
>>-เซอร์โธมัส ฟาวเวล บั๊กซ์ตัน

>>หนึ่งในเทคนิคที่ดีที่สุดในการเอาชนะนิสัยผัดวันประกันพรุ่ง
>>และทำงานได้มากขึ้นและเร็วขึ้นก็คือลงมือทำงานที่ยากที่สุดของคุณก่อน
>>นี่คือการ " กินกบของคุณ " ที่แท้จริง มันเป็นทักษะส่วนบุคคลในการบริหาร
>>ที่ยากที่สุดและสำคัญที่สุดเริ่มต้นตอนเช้าด้วยงานที่ใหญ่ที่สุดและสำคัญที่สุด
>>คือ สิ่งตรงข้ามกับที่คนส่วนใหญ่ทำ ระเบียบวินัยนี้จะทำให้คุณเลิกนิสัย ผัดวัน
>>ประกันพรุ่งและทำให้อนาคตอยู่ในกำมือคุณ
>>>>>>>>การเริ่มต้นแต่ละวันด้วยงานที่ยากที่สุดเป็นการเริ่มต้นแบบก้าวกระโดด
>>ที่ดี คุณจะมีไฟมากขึ้น และจะทำงานได้ผลดีมากขึ้น
>>>>>>>>ในวันที่คุณเริ่มลงมือทำงานสำคัญโดยทันทีทันควัน คุณจะรู้สึกดีกับตัว
>>คุณเองและกับงานของคุณมากกว่าคนอื่นๆ คุณจะรู้สึกมีอำนาจมากขึ้น ควบคุม
>>ตัวเองได้มากขึ้นและรับผิดชอบดูแลชีวิตตัวเองได้มากกว่าเวลาอื่น
>>>>>>>สร้างนิสัยเริ่มทำงานที่ยากที่สุดก่อนแล้วคุณจะไม่ต้องมองย้อนกลับ
>>คุณจะกลายเป็น หนึ่งในคนที่มีประสิทธิภาพมากที่สุดในคนรุ่นคุณ...............

>>กินกบตัวนั้นซะ!!! จงมองตัวเองว่าเป็นงานที่กำลังคืบหน้า
จงเทใจให้กับการเพาะนิสัย
>>เป็นคนมีผลงานสูงด้วยการฝึกซ้ำแล้วซ้ำเล่าจนกระทั่งมันกลายเป็นเรื่องอัตโนมัติและ
>>กลายเป็นเรื่องง่าย
>>>>>>>>หนึ่งในวลีที่มีอนุภาพมากที่สุดซึ่งคุณสามารถเรียนรู้และนำมาใช้ได้ก็คือ
>>" เพื่อวันนี้เท่านั้น! "อย่าวิตกเรื่องการเปลี่ยนแปลงชีวิตตัวเอง
ถ้ามันฟังเหมือนเป็น
>>ความคิดที่ดี จงทำมัน" เพื่อวันนี้เท่านั้น"
>>>>>>>>บอกกับตัวเองว่า " เพื่อวันนี้เท่านั้น ฉันจะวางแผนเตรียมการ
และเริ่มต้นงาน
>>ที่ยากที่สุดก่อนจะทำอย่างอื่น
"แล้วคุณจะต้องทึ่งกับความแตกต่างที่เกิดขึ้นในชีวิตคุณ

- ----------------------------------------------------------------------------------------------
คุณ พร้อมแล้วรึยัง
กับรูปแบบการทำงานง่ายๆจากที่บ้าน Click Here!
www.geocities.com/thaigetrich/easywork ,
หรือ Tel. 0-2277-7850 กด 25
- -----------------------------------------------------------------------------------------------
ขออภัยหากเป็นการรบกวน และหากไม่ต้องการให้ส่งข่าวสารมายังท่านอีก

กรุณาเมลล์มาที่ easy...@maildozy.com หัวข้อ unsub
- --#MYBOUNDARY#--

------------------------------

Date: Fri, 21 Mar 2003 17:39:20 +0100 (CET)
From: Harti Brandt <bra...@fokus.fraunhofer.de>
Subject: Re: Build options for kernel modules

On Fri, 21 Mar 2003, The Anarcat wrote:

TA>On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote:
TA>> On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote:
TA>> > On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote:
TA>> > > Hi there,
TA>> > >
TA>> > > Excuse my stupid question, but I seem to have no time to do the
TA>> > > investigation by myself right now so I'd be glad to receive a brief
TA>> > > answer from someone who has the information.
TA>> > >
TA>> > > As far as I can see, kernel modules should be built along with the
TA>> > > kernel for the only reason of keeping their mutual interfaces in
TA>> > > sync, has a source file defining such an interface changed. Is
TA>> > > there currently no way to go further and affect a kernel module's
TA>> > > built-in features with kernel config file options, besides modifying
TA>> > > makefiles in /sys/modules?
TA>> > I think this isn't so. I have been already tried to compile some modules
TA>> > without compiling kernel and this trye has successful result, but without
TA>> > change options.
TA>> > I think modules must be build with same or less imports and same or more export to be correct
TA>> > for loading.
TA>>
TA>> Yeah, it's all right to compile modules w/o the kernel, but that's
TA>> not exactly what I was asking about. My question was whether "option
TA>> FOO" lines from a kernel configuration file could influence modules.
TA>
TA>I'm pretty sure they do. A great example is IPFIREWALL_* options: if
TA>they don't influence the module, I think we have a problem. ;)

How should they? The Makefiles for modules usually create the option files
that normally are create by config options themself and set the options to
1.

harti
- --
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.fraunhofer.de, ha...@freebsd.org

------------------------------

Date: Fri, 21 Mar 2003 23:36:08 +0700 (GMT)
From: FreeB...@thaimail.com
Subject: แจกฟรี ! หนังสือคู่มือคนเคยจน สำหรับผู้สนใจ....

- --#MYBOUNDARY#
Content-Type: text/plain; charset=ansi
Content-Transfer-Encoding: 8bit

กรุณาเมลล์มาที่ easy...@maildozy.com หัวข้อ unsub
- --#MYBOUNDARY#--

------------------------------

Date: Fri, 21 Mar 2003 19:47:42 +0300
From: Yar Tikhiy <y...@freebsd.org>
Subject: Re: Build options for kernel modules

On Fri, Mar 21, 2003 at 11:25:01AM -0500, The Anarcat wrote:
> On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote:
> >
> > Yeah, it's all right to compile modules w/o the kernel, but that's
> > not exactly what I was asking about. My question was whether "option
> > FOO" lines from a kernel configuration file could influence modules.
>
> I'm pretty sure they do. A great example is IPFIREWALL_* options: if
> they don't influence the module, I think we have a problem. ;)

My testing a yesterday's CURRENT has shown we did have the problem.
Everobody is invited to set "options IPFIREWALL_DEFAULT_TO_ACCEPT"
and to load the resulting ipfw.ko on a remote machine without human
access ;-))) [small print: it's a joke, don't actually do that.]

- --
Yar

------------------------------

Date: Fri, 21 Mar 2003 11:55:20 -0500
From: "Paco Hope" <pa...@cigital.com>
Subject: ld.so and hard links

Hi.

This is a really specific, technical question (and I think it's=20
fascinating to those of us who don't know the answer) about how the text =

(code) segment of a program gets loaded into memory. I'm hoping hackers=20
is the right place for this. If not, please forgive and suggest another=20
venue.

Here's my baseline assumption. If I'm wrong here, I'm only going to get=20
wronger as I go:
If I have two different programs that both use a shared library,=20
libfoo.so, the system memory maps the object code they need into the=20
processes' address spaces. There's only one copy of libfoo.so in memory, =

and the two processes each have handles into it (or maybe just to the=20
pieces of it that they use?).

Step 2 of my question. This gets closer to my real query:
Ok now consider a hard link (not a symlink) from libfoo.so to libbar.so. =

One inode, two directory entries. Consider my two programs again, one=20
linked against libfoo.so and the other linked against libbar.so. When=20
they run, how many copies of the lib{foo,bar}.so object code are in RAM? =

My current hypothesis is 1. Isn't it mmapped off the disk? The inode=20
matters, not the file name, right? With me so far? Great.

Now consider jail(8). Let's say I have two jail environments (If you=20
think I mean chroot here, go read jail(8), it's not the same. I'm=20
assuming folks on hackers know jail.). To make my first jail, I make a=20
copy of the FreeBSD stuff that my jail needs. To make the second jail, I =

create a directory hiearachy, but I *hard link* all the binaries and=20
libraries and stuff to the same inodes that the first jail uses. Is that =

clear? Let's pick a specific example: 'ln /jail1/usr/sbin/sshd=20
/jail2/usr/sbin/sshd'. Now, sshd uses /usr/lib/libz.so.2. In my example, =

I have (effectively) done 'ln /jail1/usr/lib/libz.so.2=20
/jail2/usr/lib/libz.so.2'. These are not symlinks, so this works across=20
jails. Now I launch both jails. Two sshd processes are running, one in=20
each jail.

Now the $64K question: How many instances of, for example, the libz.so.2 =

object code are in memory? Did my use of jail(8) make any difference? My =

intuition is that only one copy of the code is in memory for the same=20
reason as in step 2 above. This is the real question I am interested in.

I'm also interested in a broader question. Consider instantiating many=20
jails this way--say 50 or 100 all hard linked to the same base set of=20
files. Can we characterize in some general hand-waving way how much=20
memory (RAM) I would save doing it this way as opposed to the naive way=20
of 50 or 100 copies of the files? I am assuming that if I have 50 copies =

of the files and I run 50 processes in 50 jails, then I will use more=20
RAM than if I had 50 hard links to the same inode and ran 50 processes=20
in 50 jails from that one inode. The naive copy method will use more=20
RAM, but not 50 times more than the hard linking way.

Thank you to any who respond. I hope I'm not completely out to lunch on=20
this.

Regards,
Paco
- --
Consultant, Cigital, Inc.
http://www.cigital.com/

- -------------------------------------------------------------------------=
- ---
This electronic message transmission contains information that may be
confidential or privileged. The information contained herein is =
intended
solely for the recipient and use by any other party is not authorized. =
If
you are not the intended recipient (or otherwise authorized to receive =
this
message by the intended recipient), any disclosure, copying, =
distribution or
use of the contents of the information is prohibited. If you have =
received
this electronic message transmission in error, please contact the sender =
by
reply email and delete all copies of this message. Cigital, Inc. =
accepts no
responsibility for any loss or damage resulting directly or indirectly =
from
the use of this email or its contents.
Thank You.
- -------------------------------------------------------------------------=
- ---

------------------------------

Date: Fri, 21 Mar 2003 11:56:21 -0500
From: The Anarcat <ana...@anarcat.ath.cx>
Subject: Re: Build options for kernel modules

- --JwB53PgKC5A7+0Ej
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri Mar 21, 2003 at 07:47:42PM +0300, Yar Tikhiy wrote:
> On Fri, Mar 21, 2003 at 11:25:01AM -0500, The Anarcat wrote:
> > On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote:
> > >=20
> > > Yeah, it's all right to compile modules w/o the kernel, but that's
> > > not exactly what I was asking about. My question was whether "option
> > > FOO" lines from a kernel configuration file could influence modules.
> >=20
> > I'm pretty sure they do. A great example is IPFIREWALL_* options: if
> > they don't influence the module, I think we have a problem. ;)
>=20
> My testing a yesterday's CURRENT has shown we did have the problem.
> Everobody is invited to set "options IPFIREWALL_DEFAULT_TO_ACCEPT"
> and to load the resulting ipfw.ko on a remote machine without human
> access ;-))) [small print: it's a joke, don't actually do that.]

Woops.

- --=20
Nothing incites to money-crimes like great poverty or great wealth.
- Mark Twain

- --JwB53PgKC5A7+0Ej
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+e0Q1ttcWHAnWiGcRAqBTAJ47hg8p5fslG+ogFOJIIjT0jWnPDQCgjvVD
mtlWKU2rzvoJ/QT1P6DvE1k=
=IuaT
- -----END PGP SIGNATURE-----

- --JwB53PgKC5A7+0Ej--

------------------------------

Date: Fri, 21 Mar 2003 10:15:21 -0800
From: Tim Kientzle <kien...@acm.org>
Subject: Re: generalized mergemaster(8)

> On Thu Mar 20, 2003 at 10:15:48PM -0600, Brandon D. Valentine wrote:
>
>>I have encountered a situation in which it would be extremely handy to
>>have a generalized version of mergemaster(8) which is less specific to
>>the task of merging /etc. I need to recursively merge two directories
>>of source files in which I wish to preserve some original files, install
>>some replacement files outright, and only actually go to the trouble of
>>sdiff(1)ing those files that from the preview udiff look like they are
>>need of a merge.

One feature I've long wanted to see in mergemaster is
the ability to install an entire directory at a pop,
without having to manually inspect every single
entry in that directory. A good example is /etc/rc.d:
I would really like to be told
"/var/tmp/temproot/etc/rc.d/ and /etc/rc.d/ have 17 differing files.
(I)nstall, (D)elete, or (R)ecursively examine? [R]"
Then I could hit 'I' and update all of /etc/rc.d at once.

Someday, a curses-based mergemaster that showed a dir heirarchy
with differences clearly annotated... <sigh>

Tim

------------------------------

Date: Fri, 21 Mar 2003 20:18:28 +0100
From: Pawel Jakub Dawidek <ni...@garage.freebsd.pl>
Subject: Re: CerbNG 1.0-RC1 is now avaliable.

- --gS/sOEqITpbrYRmu
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2003 at 01:58:38AM +0100, Pawel Jakub Dawidek wrote:
[...]

Hackers... We have spend a lot of time on coding cerb, so we count and
will be very greatful for _any_ opinions, including "it suck!".

- --=20
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.

- --gS/sOEqITpbrYRmu
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iQCVAwUBPntlhD/PhmMH/Mf1AQFfdAP+NMZXbdEYB9a8p4RrLCc3+G31gvKmKUNJ
o476d2K7P+ENqM/Nv23gV1UqKFa5FZ4392jcpjtY+WpHdkw7AzgEbHQFokHrJZam
/4XWTQTESvyfxbHETuw9d6xHje1RuPdpwj8dLS9BFLiTCId9WcQ0TE3LB5zv9q7o
HJvRu4uPXW8=
=Epjj
- -----END PGP SIGNATURE-----

- --gS/sOEqITpbrYRmu--

------------------------------

Date: Fri, 21 Mar 2003 14:27:14 -0500
From: Garance A Drosihn <dro...@rpi.edu>
Subject: Re: generalized mergemaster(8)

At 10:15 AM -0800 3/21/03, Tim Kientzle wrote:
>>On Thu Mar 20, 2003, Brandon D. Valentine wrote:
>>
>>>I need to recursively merge two directories of source files in
>>>which I wish to preserve some original files, install some
>>>replacement files outright, and only actually go to the trouble
>>>of sdiff(1)ing those files that from the preview udiff look like
>>>they are need of a merge.
>
>
>One feature I've long wanted to see in mergemaster is the ability
>to install an entire directory at a pop, without having to manually
>inspect every single entry in that directory. A good example
>is /etc/rc.d/ . I would really like to be told
>
> /var/tmp/temproot/etc/rc.d/ and /etc/rc.d/ have 17 differing files.
> (I)nstall, (D)elete, or (R)ecursively examine? [R]
>
>Then I could hit 'I' and update all of /etc/rc.d at once.

At times I've asked Doug about some kind of pattern-support in
~/.mergemasterrc, where the user could specify filename-patterns
of files where they want the default action to be "install"
instead of "leave for later". There are pros and cons with that
idea, but that's what I was thinking of for the directories you
describe.

Doug has suggested that people could maybe do things with the
MM_PRE_COMPARE_SCRIPT, for special processing like this.

- --
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu

------------------------------

Date: Fri, 21 Mar 2003 20:37:46 +0100
From: Daniela <d...@liwest.at>
Subject: Lots of kernel core dumps

Hi all!

I'm getting lots of kernel core dumps on my server.
My RAM is OK, I tested it. Below are more detailed informations.
Any help would be greatly appreciated.

I'm not yet intimate with the kernel, but I'm willing to learn it all.
Thanks in advance.

Daniela

- -------------------------------------------------------------------------=
- -----

# uname -a

FreeBSD CM58-27.liwest.at 5.0-RELEASE-p3 FreeBSD 5.0-RELEASE-p3 #4: Sat M=
ar 1=20
18:08:27 CET 2003 ro...@CM58-27.liwest.at:/usr/obj/usr/src/sys/CM58-27=
=20
i386

# gdb -k kernel.debug vmcore.1=20

GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you =
are
welcome to change it and/or distribute copies of it under certain conditi=
ons.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for detail=
s.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
- ---
panic: bad pte

syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 4h4m35s
Dumping 511 MB
ata0: resetting devices ..
done
16 32 48[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 64[CTRL-C=
to=20
abort] [CTRL-C to abort] [CTRL-C to abort] 80[CTRL-C to abort] [CTRL-C t=
o=20
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to=20
abort] 96[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C t=
o=20
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to=20
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to=20
abort] 112 128 144[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]=20
[CTRL-C to abort] 160[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abor=
t]=20
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] =20
176[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 192[CTRL-C to=20
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to=20
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to=20
abort] 208 224 240 256 272 288 304 320 336 352 368 384 400 416[CTRL-C to=
=20
abort] 432 448 464 480 496
- ---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232=09=09dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc033b5e6 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c=
:364
#2 0xc033b833 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc0379fa2 in bwrite (bp=3D0xce4d4708) at /usr/src/sys/kern/vfs_bio.c=
:796
#4 0xc037b55e in vfs_bio_awrite (bp=3D0xce4d4708)
at /usr/src/sys/kern/vfs_bio.c:1643
#5 0xc0307737 in spec_fsync (ap=3D0xe0d1cb5c)
at /usr/src/sys/fs/specfs/spec_vnops.c:462
#6 0xc0306ca8 in spec_vnoperate (ap=3D0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc045fb8d in ffs_sync (mp=3D0xc40cd800, waitfor=3D2, cred=3D0xc150ae=
80,=20
td=3D0xc0584000) at vnode_if.h:612
#8 0xc038d01b in sync (td=3D0xc0584000, uap=3D0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#9 0xc033b25c in boot (howto=3D256) at /usr/src/sys/kern/kern_shutdown.c=
:273
#10 0xc033b833 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#11 0xc04b7bbb in pmap_remove_pages (pmap=3D0xc43a33bc, sva=3D0, eva=3D32=
17031168)
at /usr/src/sys/i386/i386/pmap.c:2937
#12 0xc0326572 in exit1 (td=3D0xc456f9a0, rv=3D1) at vm_map.h:228
#13 0xc033ed26 in sigexit () at /usr/src/sys/kern/kern_sig.c:1997
#14 0xc033e97a in postsig (sig=3D1) at /usr/src/sys/kern/kern_sig.c:1886
#15 0xc035b3da in ast (framep=3D0xe0d1cd48) at /usr/src/sys/kern/subr_tra=
p.c:254
#16 0xc04ac250 in doreti_ast () at {standard input}:446
- ---Can't read userspace from dump, or kernel process---

------------------------------

Date: Fri, 21 Mar 2003 15:00:57 -0500
From: Garance A Drosihn <dro...@rpi.edu>
Subject: Re: CerbNG 1.0-RC1 is now avaliable.

At 8:18 PM +0100 3/21/03, Pawel Jakub Dawidek wrote:
>On Fri, Mar 21, 2003, Pawel Jakub Dawidek wrote:
>[...]
>
>Hackers... We have spend a lot of time on coding cerb, so we
>count and will be very greatful for _any_ opinions, including
>"it suck!".

Heh. It does look interesting, but it's always a challenge
to find the time to look into new things. And anything which
attempts to improve security takes more time to evaluate than
"just plain" code changes.

- --
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu

------------------------------

Date: Fri, 21 Mar 2003 13:00:52 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: ld.so and hard links

Paco Hope wrote:
> Here's my baseline assumption. If I'm wrong here, I'm only going to get
> wronger as I go:
> If I have two different programs that both use a shared library,
> libfoo.so, the system memory maps the object code they need into the
> processes' address spaces. There's only one copy of libfoo.so in memory,
> and the two processes each have handles into it (or maybe just to the
> pieces of it that they use?).

There's one copy of the code pages. There's one copy of the unmodified
data pages. Everything is mapped COW (copy-on-write). If there are
changes to data pages or a jump table fixup, etc., each process will
gt it's own copy of the modified pages (and *only* the modified pages!).

> Step 2 of my question. This gets closer to my real query:
> Ok now consider a hard link (not a symlink) from libfoo.so to libbar.so.
> One inode, two directory entries. Consider my two programs again, one
> linked against libfoo.so and the other linked against libbar.so. When
> they run, how many copies of the lib{foo,bar}.so object code are in RAM?
> My current hypothesis is 1. Isn't it mmapped off the disk? The inode
> matters, not the file name, right? With me so far? Great.

Actually, it's the vnode that matters, not the inode or the file
name. The vnode is used as backing store, through the vnode pager,
for the pages in each process. For each file, there is only one
vnode, and one vmobject_t, corresponding to it. If data or code
pages are modified, as before, since they are COW, what happens is
that each process gets its own pmap entries to copies of the pages,
and those copies are backed using swap as backing store (swap pager).

The reason I make this distinction is that it probably would not
help you to use loopback mounts, which is a problem for you if you
wish to maintain priviledge seperation.

> Now consider jail(8). Let's say I have two jail environments (If you
> think I mean chroot here, go read jail(8), it's not the same. I'm
> assuming folks on hackers know jail.). To make my first jail, I make a
> copy of the FreeBSD stuff that my jail needs. To make the second jail, I
> create a directory hiearachy, but I *hard link* all the binaries and
> libraries and stuff to the same inodes that the first jail uses.

[ ... ]

> Now the $64K question: How many instances of, for example, the libz.so.2
> object code are in memory? Did my use of jail(8) make any difference? My
> intuition is that only one copy of the code is in memory for the same
> reason as in step 2 above. This is the real question I am interested in.

If they are hard links, they get the same vnodes. Therefore they
get the same vmobject_t's. Therefore there is a single copy in
memory, until pages are modified, at which point the modified
pages aren't shared, but the rest of the file remains shared.

> I'm also interested in a broader question. Consider instantiating many
> jails this way--say 50 or 100 all hard linked to the same base set of
> files. Can we characterize in some general hand-waving way how much
> memory (RAM) I would save doing it this way as opposed to the naive way
> of 50 or 100 copies of the files? I am assuming that if I have 50 copies
> of the files and I run 50 processes in 50 jails, then I will use more
> RAM than if I had 50 hard links to the same inode and ran 50 processes
> in 50 jails from that one inode. The naive copy method will use more
> RAM, but not 50 times more than the hard linking way.
>
> Thank you to any who respond. I hope I'm not completely out to lunch on
> this.

You could potentially save a lot of memory. *However*. You may
not want to do this, since you are defeating priviledge seperation
that is what made you want to use jails in the first place.

Specifically, using your sshd example, say I do this, and then I
end up with 50 or 100 jail instances, which I then use to do
virtual hosting for 50 or 100 different customers.

Now one customer compromises the shared copy of sshd. And can now
log into the jails of all my other customers. In other words, if
you do this, you'd better be very sure that it's read-only media,
or take other precautions.

- -- Terry

------------------------------

Date: Fri, 21 Mar 2003 13:06:57 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Lots of kernel core dumps

Daniela wrote:
> I'm getting lots of kernel core dumps on my server.
> My RAM is OK, I tested it. Below are more detailed informations.
> Any help would be greatly appreciated.
>
> I'm not yet intimate with the kernel, but I'm willing to learn it all.
> Thanks in advance.

You posted to -hackers, but this is an older version of -current.

This is a known problem. I believe it was fixed on the HEAD
branch in the last couple of days (i.e. if you update your -current
sources, then the problem should be resolved).

See recent discussions about "trap 12" and "panic" in "NFS", and
older discussions about the same panic in "smbfs".

If you are already running today's -current, you can always try:

options DISABLE_PSE
options DISABLE_PG_G

These are in GENERIC, so if it isn't in your "SM58-27" kernel
config file, then it's because you went out of your way to take
them out. I mention this possibility because of:

> panic: bad pte

- -- Terry

------------------------------

Date: Fri, 21 Mar 2003 13:10:00 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: Re: Lots of kernel core dumps

- --s/l3CgOIzMHHjg/5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2003 at 08:37:46PM +0100, Daniela wrote:
> Hi all!
>=20
> I'm getting lots of kernel core dumps on my server.
> My RAM is OK, I tested it. Below are more detailed informations.
> Any help would be greatly appreciated.

I think this was fixed after 5.0-R..upgrade to -current and try again.

Kris

- --s/l3CgOIzMHHjg/5
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+e3+oWry0BWjoQKURAlTIAJ0QlTKYQGJS32bA1x5tcr1YDPbtwACgl/jm
WamtqFzee6Qb0WEoGNIwLdM=
=LxpO
- -----END PGP SIGNATURE-----

- --s/l3CgOIzMHHjg/5--

------------------------------

Date: Fri, 21 Mar 2003 22:26:01 +0100
From: Daniela <d...@liwest.at>
Subject: Re: Lots of kernel core dumps

On Friday 21 March 2003 22:10, Kris Kennaway wrote:
> On Fri, Mar 21, 2003 at 08:37:46PM +0100, Daniela wrote:
> > Hi all!
> >
> > I'm getting lots of kernel core dumps on my server.
> > My RAM is OK, I tested it. Below are more detailed informations.
> > Any help would be greatly appreciated.
>
> I think this was fixed after 5.0-R..upgrade to -current and try again.
>
> Kris

I'm running 5.0-RELEASE, not -CURRENT.

------------------------------

Date: Fri, 21 Mar 2003 14:15:14 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: Re: Lots of kernel core dumps

- --y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2003 at 10:26:01PM +0100, Daniela wrote:
> On Friday 21 March 2003 22:10, Kris Kennaway wrote:
> > On Fri, Mar 21, 2003 at 08:37:46PM +0100, Daniela wrote:
> > > Hi all!
> > >
> > > I'm getting lots of kernel core dumps on my server.
> > > My RAM is OK, I tested it. Below are more detailed informations.
> > > Any help would be greatly appreciated.
> >
> > I think this was fixed after 5.0-R..upgrade to -current and try again.
> >
> > Kris
>=20
>=20
> I'm running 5.0-RELEASE, not -CURRENT.

I know, but 5.0-RELEASE was

a) A work-in-progress, not a perfect, bug-free release

b) A snapshot of 5.0-CURRENT

You read the 5.0 Early Adopter's Guide, right? Bugs like this are
expected at this stage in the development process, and if you
encounter them then you need to either give up on 5.x and go back to
4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed there.

Kris
- --y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+e47yWry0BWjoQKURAjIyAKCxQ+vpj9HzPKneyNv5GW7aZxbsyACeKU/L
BPXI5Cp6Dlznv+aycbiwT7g=
=XkDg
- -----END PGP SIGNATURE-----

- --y0ulUmNC+osPPQO6--

------------------------------

Date: 22 Mar 2003 13:33:09 +1030
From: "Daniel O'Connor" <doco...@gsoft.com.au>
Subject: Re: ld.so and hard links

On Sat, 2003-03-22 at 07:30, Terry Lambert wrote:
> You could potentially save a lot of memory. *However*. You may
> not want to do this, since you are defeating priviledge seperation
> that is what made you want to use jails in the first place.

There's a Linux Jail like thing called vserver, it has a feature where
you hardlink a whole bunch of stuff for different jails (it has tools
for building a set of jails from a given tree). It does a copy on write
for any of these hardlinked files so you don't get the security issue.

No idea if it's possible to implement something like that for a jail :)

- --
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5

------------------------------

Date: Fri, 21 Mar 2003 23:25:38 -0700
From: <sor...@cydem.org.ua>
Subject: Re: misc/41772: can't disable keybell [PATCH]

> http://www.freebsd.org/cgi/query-pr.cgi?pr=41772
This appears to be _VERY_ old problem (I don't remember
it on 2.2.7-RELEASE, though)
In short: the beeper still produces noises (clicks) when
shut up with `kbdcontrol -b off`

Finally I got some time to look at
'sys/dev/syscons/syscons.c'. However, I only speak
i386 Asm fluently (no C at all yet), so could
someone plz (fix?) this 3-line 'patch' and commit
it? I'd really like to see it MFC'ed in 4.8-RELEASE
(as well a this one:
'http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/44257' -
it works well for my EIDE controller).

FreeBSD 4.6.2-RELEASE:
=======================8<=======================
- --- ./syscons.c.ORIG Fri Mar 21 23:10:05 2003
+++ ./syscons.c Fri Mar 21 23:10:37 2003
@@ -3385,6 +3385,9 @@
if (scp != scp->sc->cur_scp && (scp->sc->flags & SC_QUIET_BELL))
return;

+ if (!(duration && pitch))
+ return;
+
if (scp->sc->flags & SC_VISUAL_BELL) {
if (scp->sc->blink_in_progress)
return;
=======================8<=======================

21.03.2003; 23:20:26
[SorAlx] http://cydem.org.ua/

------------------------------

End of freebsd-hackers-digest V5 #751
*************************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message

0 new messages