Re: Making /etc/defaults/rc.conf a configuration file.
Neil Blakey-Milner wrote: > > Hi, > > With these patches, and the new tiny util 'sourceconf', we can make > /etc/defaults/rc.conf and /etc/defaults/periodic.conf configuration > files again, such that they can be parsed by things other than 'sh'. I have been very sick the last few days, so I haven't commented on this yet. > It also allows you to set 'rc_conf_files' (or, actually, whatever you > set filevar to) in lower places than the default file, so that you don't > change the default file. Can you give more details about this process? I'm not sure how it would work to change the list of conf files other than in the default location if you're going to source the defaults anyway. > This only shows how to replace things using rc.conf - changing scripts > to use periodic.conf is as simple as replacing > > if [ -r /etc/defaults/periodic.conf ] > then > . /etc/defaults/periodic.conf > source_periodic_confs > fi > > with > > rcfile=/etc/defaults/periodic.conf listvar=periodic_conf_files . /etc/sourceconf But you're basically doing exactly the same thing(s), just in a different order. With all due respect to Neil, I stated previously that I feel like this is a solution in search of a problem. I'm not arguing for the status quo necessarily, I'm just concerned that when something comes along down the road that *does* need to do something differently, we will end up redoing all of this stuff again. For what it's worth, I do not oppose the change, however I would like to see some comments in the sourceconf file as to what is going on where and why. I can't help feeling that sourceconf_start and sourceconf_dosrc could just as easily be in the same function, but in my current state I'm probably missing something. Also, in the sc.patch the entry for /etc/rc has ". /etc/sourceconfs" instead of ". /etc/sourceconf". In any case, if the patch has been thoroughly tested under a variety of different configurations, it's probably worth putting in -current. It would probably be worth comparing what you're doing here to the work that's happening on the rc files in netbsd that some here have discussed bringing over, in whole or in part. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE drives doing BBR?
> > Or do I just write nul's to the block or 0's, and it's supposed to do it > > automatically? or do I just punt. > > 'dd if=/dev/zero of=/dev/ad1 bs=4k' works great; takes about an hour to > scrub the entire disk. Run until clean. Running it right now in fact. Err, Umm, I wouldn't assume that drives always know that writes have failed. Do a read pass too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE drives doing BBR?
On Wed, 4 Oct 2000, Jaye Mathisen wrote: > Remember reading on hackers somewhere that newer drives like IBM supported > this feature. I'm getting a few bad blocks on a 75GB IBM drive (at least > according to the ata driver), and rather than replacing it and moves on, > the disk basically dies. > > However, I run the IBM drive fitness test, it works some magic in there > writing data to the drive, and the drive is back, and the failed block now > seems fine. > Ran into this today actually ... Yes the IBMs do automatic block remapping ... you may have to scrub the disk a few times to get the bad blocks out. Now you have 75GB of potentially bad blocks so you have to scrub pretty completely. > Or do I just write nul's to the block or 0's, and it's supposed to do it > automatically? or do I just punt. 'dd if=/dev/zero of=/dev/ad1 bs=4k' works great; takes about an hour to scrub the entire disk. Run until clean. Running it right now in fact. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anonymous memory map vs mmap on /dev/zero
On Wed, 4 Oct 2000, FengYue wrote: > It seems that mmap on /dev/zero is more portable. no really, It won't work at all correctly on linux, and on Tru64 it does the totally wrong thing, but the (fd = -1, MAP_ANONYMOUS) does the right thing on tru64. It's disappointing that this works so unportably :-( ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
anonymous memory map vs mmap on /dev/zero
Hi, excluding the extra kernel calls of open()/close() on /dev/zero, which one of the following would be more efficient: 1) Using mmap on /dev/zero 2) Using mmap with MAP_ANON flag The purpose is, ofcourse, to share the memory (R&W) among all child processes. It seems that mmap on /dev/zero is more portable. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE drives doing BBR?
Jaye Mathisen wrote: > > Used ABBR on SCSI disks all the time, very nice. > > Remember reading on hackers somewhere that newer drives like IBM supported > this feature. I'm getting a few bad blocks on a 75GB IBM drive (at least > according to the ata driver), and rather than replacing it and moves on, > the disk basically dies. > > However, I run the IBM drive fitness test, it works some magic in there > writing data to the drive, and the drive is back, and the failed block now > seems fine. > > So is there some equivalent of camcontrol or scsicmd for ATA drives that > turns on this feature, and allows my running system to take advantage of > it? > > Or do I just write nul's to the block or 0's, and it's supposed to do it > automatically? or do I just punt. Or a possible third option: A 75GB IBM HD is probablly still within the warentee period. Assuming you don't play fetch with your dog and the HD, you can probabally get it replaced. -- _ __ ___ ___ __ / \/ \ | ||_ _|| _ \|___| | Jason Andresen -- [EMAIL PROTECTED] / /\/\ \ | | | | | |/ /|_|_ | Views expressed may not reflect those /_/\_\|_| |_| |_|\_\|___| | of the Mitre Corporation. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IDE drives doing BBR?
Used ABBR on SCSI disks all the time, very nice. Remember reading on hackers somewhere that newer drives like IBM supported this feature. I'm getting a few bad blocks on a 75GB IBM drive (at least according to the ata driver), and rather than replacing it and moves on, the disk basically dies. However, I run the IBM drive fitness test, it works some magic in there writing data to the drive, and the drive is back, and the failed block now seems fine. So is there some equivalent of camcontrol or scsicmd for ATA drives that turns on this feature, and allows my running system to take advantage of it? Or do I just write nul's to the block or 0's, and it's supposed to do it automatically? or do I just punt. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Automatic updates (was Re: How long for -stable...)
In message <[EMAIL PROTECTED]> Jordan Hubbard writes:
: > I think that we can do a lot with cvsupd. I've used cvsupd to grab
: > binaries on an experimental basis and it seems to work great. I've
:
: Hmmm. Does cvsupd also move a target out of the way if it already
: exists and it's in the process of replacing it? What if the target is
: chflag'd but can be unprotected at the current security level?
:
: What I'm trying to say is that if you have "/sbin/init" and cvsupd is
: about to replace it, I would expect the steps to be something like
: this:
:
: Receive new init as /sbin/init.${pid} (or something)
: |
: |<+
: | Yes |Yes
: \/ No |No
: Mv /sbin/init.${pid} /sbin/init --> chflags noschg /sbin/init --> Fail
:|
:| Yes
:\/
:Done
:
: If cvsupd does that or can be gimmicked to do that (add
: --potentially-hose-me flag? ;) then I'd say it's a serious
: contender for being part of a binary update process.
I don't know. I seem to recall that jdp told me at the talk I gave
last year that it just wipes the flags completely and doesn't honor
them.
I think it deals well with this, but I've not tried to replace init on
a running system. Given that the Pluto upgrade went well, I'd expect
the answer is yes, it works.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Automatic updates (was Re: How long for -stable...)
> > I think that we can do a lot with cvsupd. I've used cvsupd to grab > > binaries on an experimental basis and it seems to work great. I've > > Hmmm. Does cvsupd also move a target out of the way if it already > exists and it's in the process of replacing it? What if the target is > chflag'd but can be unprotected at the current security level? I know the author, and I'll bet you he could be convinced to modify it to do what we need. *grin* Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Automatic updates (was Re: How long for -stable...)
> I think that we can do a lot with cvsupd. I've used cvsupd to grab
> binaries on an experimental basis and it seems to work great. I've
Hmmm. Does cvsupd also move a target out of the way if it already
exists and it's in the process of replacing it? What if the target is
chflag'd but can be unprotected at the current security level?
What I'm trying to say is that if you have "/sbin/init" and cvsupd is
about to replace it, I would expect the steps to be something like
this:
Receive new init as /sbin/init.${pid} (or something)
|
|<+
| Yes |Yes
\/ No |No
Mv /sbin/init.${pid} /sbin/init --> chflags noschg /sbin/init --> Fail
|
| Yes
\/
Done
If cvsupd does that or can be gimmicked to do that (add
--potentially-hose-me flag? ;) then I'd say it's a serious
contender for being part of a binary update process.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Automatic updates (was Re: How long for -stable...)
In message <[EMAIL PROTECTED]> Nate Williams writes: : [ Culled the list way down, and moved it to -hackers ] : : > We could also look into providing an "update" command or something : > which would pull either sources or binaries over from a snapshot box : > and make the process of getting up to the branch-head a lot easier. : > It's long been on my wishlist and I'm at the point where I'd be : > willing to devote some BSDi resources to both writing the software : > and setting up a build box for creating the relevant binaries on an : > ongoing basis. : : Whoo hoo. Sounds like a *great* plan! I think that we can do a lot with cvsupd. I've used cvsupd to grab binaries on an experimental basis and it seems to work great. I've also worked at companies that did this on all their workstations on boot and they updated one area and then rebooted 20-odd machines to update them. Not without its problems, but a lot less hair than even an installworld. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to allocate kernel memory with PG_NC_PCD set
The subject says it all :) What is the best way to allocate kernel memory with non-cacheable bit set? Or, better yet, is it possible to change caching bit on an already kmalloc'ed memory block? Will something like this work? pt_entry_t pte; pte = (pt_entry_t)vtopte(vaddr); *pte |= PG_NC_PCD; invtlb(); -- E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]> Date: 04-Oct-00 Time: 12:12:22 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
