Re: rfork()
This is an example only. It takes a *BUNCH* of arcane assembly to make
it work.
I would suggest *EXTREME* caution when using a completely cloned address
space such as RFPROC|RFMEM generate. Normal library calls cannot be made
by the child safely. Thread libraries will also not work since they
expect the pthread model.
This is not portable. The assembly is designed for ELF libraries.
-Matt
/*
* FTEST.C
*/
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
void fubar(void *data);
int
main(int ac, char **av)
{
pid_t pid;
int stackSize = 64 * 1024;
char *stack = malloc(stackSize);
volatile int v = 0;
printf(parent pid %d\n, (int)getpid());
fflush(stdout);
pid = ffork(fubar, v, stack, stackSize);
printf(child pid returned to parent %d\n, pid);
/*
* If stack is not split, then child should be able to
* increment v.
*/
for (;;) {
sleep(1);
printf(%d\n, v);
}
exit(1);
}
void
fubar(void *data)
{
int *pdata = data;
for (;;)
++*pdata;
_exit(0);
}
/*
* FFORK.S
*/
.globl ffork
.text
/*
* ffork(func, data, stack, stackSize)
*/
ffork:
/*
* Setup stack frame for new stack and store in register
* which will not be destroyed by call to rfork, %ebx.
*
* newsp - func
* data
*/
pushl %ebx
movl12+4(%esp),%ebx
addl16+4(%esp),%ebx
subl$16,%ebx/* newsp = %ebx = stack + stackSize - 16 */
movl4+4(%esp),%eax
movl%eax,0(%ebx)/* func */
movl8+4(%esp),%eax
movl%eax,4(%ebx)/* data */
/*
* Call rfork() syscall. This is arcane I'm afraid because we cannot
* use a 'call' due to possible stack reuse by one or the other
* process. Instead we do a direct syscall.
*
* %edx is returned non-zero to the child, zero to the parent. %eax
* is returned as the child pid to the parent, and garbage to the
* child.
*/
pushl $48 /* RFPROC|RFMEM */
pushl $0 /* dummy*/
movl$0xfb,%eax /* rfork syscall number */
int $0x80 /* syscall */
cmpl$0,%edx /* edx returns 0 to parent, pid in %eax */
jne child
/*
* parent returns pid of child in %eax ( returned by syscall ), and
* controls original stack.
*/
addl$8,%esp /* scrap syscall args */
popl%ebx/* pop saved registers */
ret /* return to parent */
/*
* child must run function in new stack frame without messing with
* old stack frame ( which might already be popped and reused by the
* parent )
*/
child:
movl%ebx,%esp /* switch stacks*/
movl%esp,%ebp /* setup new frame pointer */
popl%eax/* pop function address */
call*%eax /* call function*/
jmp __exit /* system exit on return*/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Mike Smith wrote: But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. Right :) ... so we lose. 8( Well, depends on POV I guess... Soren, please take a little time to understand what Justin is talking about. The parts of CAM that are relevant to you are the queueing support, infrastructure, and the separation between the interface controller and the peripheral driver, something that you've indicated to me several times that you simply don't grasp. The main driving force here is that I want as much performance as I can possibly get out of modern ATA/ATAPI hardware, plus have a driver as simple as possible to arrive at that goal. However, all that I've been doing so far is to get the lowlevel code redone so probes are faster etc etc, all the highlevel code is more or less reused old hat things for now. There is nothing that hinders anyone in doing all the (apparently) needed changes to CAM, and have it call what I've (re)done so far. However I dont have any plans for that on my whiteboard *currently*. If consensus can be reached that shows that the project is not interested in it being done this way, please, just tell me and I'll pack up my bits, I can deal with having yet another set of patches locally. Can you grasp that ?? (yes offence taken). Taking advantage of all the code and design that's already been implemented in the CAM framework will make your life easier, not harder. It's not necessary to write a translation layer at all, if such a thing offends your sensibilities. Maybe, later, but I still need to get all the lowlevel stuff into shape, and have it working on you average ATA/ATAPI iron, which is not exactly trivial, I need support for DMA on god knows which different PCI chipsets, I need the lowlevel code to deal with ATA4's braindead way of doing tagged queuing, etc etc etc.. Then when all this is working we can talk about having the top layer(s) redone in the CAM way or what we have at that point in time. OK ?? -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Justin T. Gibbs wrote: My main complaint so far about the new ATAPI stuff is that it duplicates or lacks (assuming it will be implemented) much of what CAM would have given for almost free: - Interrupt driven configuration That there allready, if we mean the same thing here. Right. Its duplicated functionality. Nope, not exactly.. - Peripheral driver to device routing Such as ? Such as the ability to have more than one driver share the same device, command generation counts and priority queuing to allow correct 'replay' of overlapped commands when an error occurs, etc. See: http://www.freebsd.org/~gibbs/cam.html That will probably need changes to work with ATA4's tagged queing at least... - an extensible error recovery framework Well, here is room for improvement, I haven't put any real error checking code in there by now, it will just fail and report that for now. This is alpha level code remember. But how will you deal with errors especially when there are overlapped commands? CAM already deals with this in a very clean way. When an error occurs, the controller driver freezes the queue of commands to the erring device, notifies the peripheral driver of the error, and allows the driver to insert error recovery actions before any other commands are ever released to the device. This even allows you to toss back unexecuted but queued commands at the controller level to be reinserted into the transport layer's command queue to ensure proper ordering. This all plays off of the priority features inherent in how transactions are queued. Command queuing was a major factor in why I wrote the CAM code. Solving these issues is not trivial. Agreed, but have you looked at how ATA4 handles queing ?? - an aplication pass-thru interface Hmm, what for ?? cdrecord, a userland disk format utility, camcontrol functionality, etc. etc. He he, ATAPI dont need cdrecord as all ATAPI burners use the same command set (MMC), where your average SCSI burner has its own propietary command set (well, the ATA/ATAPI guys did get one thing right :) ), There might be an idea for formatting utils for LS120/ZIP drives, ATA harddisks should not be formatted, in fact the ignore the command more or less. OK, I'm done discussing this (se my other mail), I'd rater spend my (very limitted) time productively. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: unable to use cdrecord on an ATAPI CD-R under 2.2.8.
It seems Christopher J. Michaels wrote: Well, I'm sorry to say that it looks like I've found the answer to my own question. I found after this posting (by looking at dmesg) that I was getting the following error. acd0: rezero failed I did some searching and found several postings in -current that said my drive, a MITSUMI CR-2600TE, does not support the REZERO command and is therefore not going to work, at least with the acd driver I have running now. You could try to change the rezero function with a call to the start device function instead, that should work. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Possible fix for rc.conf
Why do we need to have ANY of the file inclusion in /etc/defaults/rc.conf?
Shouldn't that file simply be definitions of variables?
IMHO, the logic should be in rc itself.
On Sat, 20 Mar 1999, Scot W. Hetzel wrote:
What does everyone think about using this at the end of
/etc/defaults/rc.conf?
for i in ${rc_conf_files}; do
if [ $0 != $i ]; then
if [ -f $i ]; then
. $i
fi
else
echo Error: $0 isn't allowed to re-load $i.
echo Error: Please do not copy /etc/defaults/rc.conf to
/etc/rc.conf
fi
done
If someone does copy the /etc/defaults/rc.conf to /etc/rc.conf, /etc/rc.conf
will not reload it's self, thus it will never get stuck in an endless loop.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
frontpage and current 4.0
A quick crossposted letter; continue in the most appropriate group at your choice. Will frontpage (fp30.bsdi3.tar.Z) run on current 4.0? I tried building apache13-fp from the ports. I had to edit apache's configure to accept the parameter i386--freebsd4.0 (I guess it should be i386-unknown-freebsd4.0) to compile. But fpsrvadm.exe just dumps core when make install runs. So is current 4.0 and fp30 compatible? l...@neland.dk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: frontpage and current 4.0
Leif Neland wrote: But fpsrvadm.exe just dumps core when make install runs. So is current 4.0 and fp30 compatible? Some mods were recently committed to cater for support of large (in terms of RAM) systems; these break BSDI compatibility and might be the root of your problems. Best Regards, PYD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: frontpage and current 4.0
Leif Neland r...@neland.dk writes: Will frontpage (fp30.bsdi3.tar.Z) run on current 4.0? Only if your kernel is configured for a 256 MB address space. See section 13.15 in the FAQ for instructions on how to do this. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
make release fails
Hiho, I'm using a 3.1-STABLE system, up to date with a current CVS-tree. No I would like to install a few other boxes as well, so I thought 'make release' would be the thing. I set the RELEASETAG to RELENG_3, make release then seems to run fine, until it wants to build kerberosIV. This fails with 'don't know how to make k_getpwuid.c' (or similar). Now the thing is, I'm not USA_RESDIDENT, so I don't have Kerberos installed, and I don't want it in the release anyway. I tried to set 'NOKERBEROS', 'NOCRYPT', etc, but it doesn't seem to work. But I have to admit, that I made a 'make rerelease' after the build broke down. I didn't want it to remove the whole chroot-tree and check the whole stuff out again, since this takes AGES (even on my sort of fast machine). If anyone has any hints, how to avoid building kerberos, preferrably without having to do a 'make release' and set the trees up from scratch again, I would be grateful. Any other general hints for 'make release' or some more documentation apart from /usr/src/release/Makefile would be nice, as well. Btw, I'm not subscribed to any of the mailing-lists, I'd rather browse the archives. So if anyone likes to answer, please include a cc: to my personal address, or at least give me hint like 'Watch the ...-list' or 'You _should_ be subscribed to ...'. Cheers, Daniel -- IRCnet: Mr-Spock - Agartim billiard bumba m'abdul in papejim twista - rumba rock n rolla. Leik'ab mai. Spirzon Heroin se'osit gaula. - - Marijuana esit gaula. Haschisch. Opis. - RL: Daniel Lang * d...@leo.org * +49 89 8540017 * http://www.leo.org/~dl/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rfork()
On Sat, 20 Mar 1999, Matthew Dillon wrote: : rfork(RFMEM) doesn't easily work from C. You need to : create an assembly stub. : : -- : John | Never try to teach a pig to sing, : dy...@iquest.net | it makes one look stupid : jdy...@nc.com | and it irritates the pig. : : : I've seen about 6 people ask about this because the manual lies about : what is done. I asked a while back about it, and John was kind enough : to dig up some code that used rfork to properly split the stack should : I try to dig it up? : : In the meantime, can someone commit this or suggest something? : :For the suggest something, you realize that with Richard's VM_STACK code it :should be relatively trivial to make this automatic (suggestion: add :RFSTACK flag). : : Brian Feldman _ __ ___ ___ ___ : gr...@unixhelp.org_ __ ___ | _ ) __| \ : http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | : FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ If the goal is to completely share the address space, which RFMEM does, you can't split anything, not even the stack. It sure would be useful if there were a standard clib call adequate for calling rfork() and calling a function in the child w/ a new stack. Hence the NEW flag RFSTACK. Why would this be a bad thing? This would keep the old behavior and allow much nicer new behavior. I didn't suggest changing the old behavior. This would just greatly simplify things so all of the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a stack and as soon as the rfork() returned movl newstack,%esp and whatnot, wouldn't this be a pretty simple solution? -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rfork()
On Sun, Mar 21, 1999 at 12:48:07AM -0800, Matthew Dillon wrote: This is an example only. It takes a *BUNCH* of arcane assembly to make it work. I would suggest *EXTREME* caution when using a completely cloned address space such as RFPROC|RFMEM generate. Normal library calls cannot be made by the child safely. Thread libraries will also not work since they expect the pthread model. This is not portable. The assembly is designed for ELF libraries. The linux threads port at http://lt.tar.com/linuxthreads.tar.gz contains an implementation of a linux clone call using rfork. An alternative assembly language interface to rfork, originally posted to -hackers by John Dyson last summer, is attached. This was part of a larger posting of some kthread code. Check the mail archives for the complete posting by John on August 20, titled rfork stuff, which includes an example using thr_fork. No reason I can see that thr_fork and/or clone couldn't be added to libc. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 .file rf.S #include sys/syscall.h #include DEFS.h #include SYS.h #define KERNEL #include sys/errno.h #undef KERNEL #undef DEBUG /* *8 12 162024 28 * thr_fork(flags, stack, startrtn, startarg, userrtn, arg); * * flags: RF* flags for rfork in unistd.h. * subr: subroutine to run as a thread. * stack: top of stack for thread. * arg: argument to thread. */ .stabs rf.S,100,0,0,Ltext0 .text Ltext0: .type CNAME(thrfork),@function .stabd 68,0,1 ENTRY(thrfork) pushl %ebp movl%esp, %ebp pushl %esi /* * Push thread info onto the new thread's stack */ movl12(%ebp), %esi / get stack addr subl$4, %esi movl28(%ebp), %eax / get user argument movl%eax, (%esi) subl$4, %esi movl24(%ebp), %eax / get user thread address movl%eax, (%esi) subl$4, %esi movl20(%ebp), %eax / get internal argument movl%eax, (%esi) subl$4, %esi movl16(%ebp), %eax / get internal subroutine movl%eax, (%esi) .stabd 68,0,2 /* * Prepare and execute rfork */ pushl 8(%ebp) pushl %esi lealSYS_rfork, %eax KERNCALL jb 2f .stabd 68,0,3 /* * Check to see if we are in the parent or child */ cmpl$0, %edx jnz 1f addl$8, %esp popl%esi movl%ebp, %esp popl%ebp ret .p2align 2 /* * If we are in the child (new thread), then * set-up the call to the internal subroutine. If it * returns, then call _exit. */ .stabd 68,0,4 1: movl%esi,%esp #ifdef DEBUG movl%esp, _stackaddr movl(%esp), %eax movl%eax, _stack movl4(%esp), %eax movl%eax,_stack+4 movl8(%esp), %eax movl%eax,_stack+8 movl12(%esp), %eax movl%eax,_stack+12 #endif popl%eax #ifdef DEBUG movl%eax,_fcn #endif call%eax addl$12, %esp /* * Exit system call */ callPIC_PLT(_exit) .stabd 68,0,5 2: addl$8, %esp popl%esi movl%ebp, %esp popl%ebp jmp PIC_PLT(HIDENAME(cerror)) .stabs thrfork:f67,36,0,6,CNAME(thrfork) Lfe1: .sizeCNAME(thrfork),Lfe1-CNAME(thrfork) #ifdef DEBUG .data .globl _stack _stack: .long 0 .long 0 .long 0 .long 0 .long 0 .globl _stackaddr _stackaddr: .long 0 .globl _fcn _fcn: .long 0 #endif #include sys/types.h extern pid_t thrfork(int flags, caddr_t stack_top, void (*internal_fn)(void *, int (*)(void *), void*), void *internal_arg, int (*user_fn)(void *), void * user_arg);
Re: Possible fix for rc.conf
On Sunday, 21st March 1999, Richard Wackerbarth wrote: Why do we need to have ANY of the file inclusion in /etc/defaults/rc.conf? Shouldn't that file simply be definitions of variables? IMHO, the logic should be in rc itself. Yeah! What he said! Having code in rc.conf sucks. If there is no logic, there can be no recursion. If you are going to mix code into rc.conf you may as well just suck it back into /etc/rc and get rid of it entirely. (*) Stephen. (*) Which is silly, of course. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make release fails
Daniel, I'm guessing here, but check your existing make.conf file in /etc against the one in /usr/src/etc/make.conf. I know the newer one has an option MAKE_KERBEROSIV. See if that helps... As far as how to start where it failed, I have no idea..SORRY. I would like to know that myself. later Michael Mercer Daniel Lang wrote: Hiho, I'm using a 3.1-STABLE system, up to date with a current CVS-tree. No I would like to install a few other boxes as well, so I thought 'make release' would be the thing. I set the RELEASETAG to RELENG_3, make release then seems to run fine, until it wants to build kerberosIV. This fails with 'don't know how to make k_getpwuid.c' (or similar). Now the thing is, I'm not USA_RESDIDENT, so I don't have Kerberos installed, and I don't want it in the release anyway. I tried to set 'NOKERBEROS', 'NOCRYPT', etc, but it doesn't seem to work. But I have to admit, that I made a 'make rerelease' after the build broke down. I didn't want it to remove the whole chroot-tree and check the whole stuff out again, since this takes AGES (even on my sort of fast machine). If anyone has any hints, how to avoid building kerberos, preferrably without having to do a 'make release' and set the trees up from scratch again, I would be grateful. Any other general hints for 'make release' or some more documentation apart from /usr/src/release/Makefile would be nice, as well. Btw, I'm not subscribed to any of the mailing-lists, I'd rather browse the archives. So if anyone likes to answer, please include a cc: to my personal address, or at least give me hint like 'Watch the ...-list' or 'You _should_ be subscribed to ...'. Cheers, Daniel -- IRCnet: Mr-Spock - Agartim billiard bumba m'abdul in papejim twista - rumba rock n rolla. Leik'ab mai. Spirzon Heroin se'osit gaula. - - Marijuana esit gaula. Haschisch. Opis. - RL: Daniel Lang * d...@leo.org * +49 89 8540017 * http://www.leo.org/~dl/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rfork()
On Sat, Mar 20, 1999 at 11:43:14PM -0800, Matthew Dillon wrote: :For the suggest something, you realize that with Richard's VM_STACK code it :should be relatively trivial to make this automatic (suggestion: add :RFSTACK flag). : : Brian Feldman _ __ ___ ___ ___ : gr...@unixhelp.org_ __ ___ | _ ) __| \ : http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | : FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ If the goal is to completely share the address space, which RFMEM does, you can't split anything, not even the stack. It sure would be useful if there were a standard clib call adequate for calling rfork() and calling a function in the child w/ a new stack. Possibilities for the clib call are noted in separate messages. The problem with adding an RFSTACK flag to the rfork call is that a lot of the time the caller of rfork wants to control the stack address. If you just add an RFSTACK flag, the system will have to pick the address. The linux clone syscall (different from the linux clone libc function) takes two additional parameters that rfork doesn't. One of those parameters is the stack TOS address, and the other is the exit signal the clone'd process should return (so kthreads can return different exist signals from child processes). As long as rfork doesn't take a TOS parameter as input, you will have to use an assembly language wrapper to rfork to graft the stack onto the child process. The primary reason I've seen, that the caller of rfork wants to control the TOS address, is so there is an efficient thread_self function. By marrying TLS to the stack, and using aligned/uniformly spaced stack addresses, thread_self can examine its stack, and derive the address of the TLS efficiently. Now, it would be very nice to find a better way to do the thread_self stuff. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rfork()
:Hence the NEW flag RFSTACK. Why would this be a bad thing? This would keep :the old behavior and allow much nicer new behavior. I didn't suggest :changing the old behavior. This would just greatly simplify things so all of I think Richard Seaman has it right: the stack needs to be passed. Why don't we simply implement the linux clone()? It sounds to me that it would be trivial. :the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a :stack and as soon as the rfork() returned movl newstack,%esp and whatnot, :wouldn't this be a pretty simple solution? No, because one of the processes may overrun the stack before the other one managed to return from rfork(). The child process cannot use the old stack at all. Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
'de' driver not updating Opkts counters in netstat ?
as the subject says, i recently noticed that the 'de' driver on 3.1 machines seems not to update regularly the Opkt field as shown by netstat. I have seen this in two different ways; on a de-only machine, the count seems to be updated every few seconds (i.e. i see two-three times the same count doing a netstat despite i am connected via telnet so the fact that i see a response means i have at least one more pkt out). on another machine (dual homed, ed+de, running a multicast router) all the counters for the 'de' driver seem stuck and i can only get them to increase by running some savage ping e.g. ping -s 1000 myfriend Any ideas ? I have another 2.2.7 machine with the 'de' driver and mrouter online and counters seem to work fine there... luigi ---+- Luigi RIZZO . EMAIL: lu...@iet.unipi.it. Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 'de' driver not updating Opkts counters in netstat ?
:as the subject says, i recently noticed that the 'de' driver on 3.1 :machines seems not to update regularly the Opkt field as shown :by netstat. I have seen this in two different ways; on a de-only :machine, the count seems to be updated every few seconds (i.e. i see :two-three times the same count doing a netstat despite i am connected :via telnet so the fact that i see a response means i have at least :one more pkt out). on another machine (dual homed, ed+de, running :a multicast router) all :the counters for the 'de' driver seem stuck and i can only get them to :increase by running some savage ping e.g. : : ping -s 1000 myfriend : :Any ideas ? : :I have another 2.2.7 machine with the 'de' driver and mrouter online :and counters seem to work fine there... : : luigi :---+- : Luigi RIZZO . I've noticed this also on the one machine I have left that uses the de driver. The Ipkt field is updated in realtime. The Opkt field is not. Very odd. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rfork()
On Sun, 21 Mar 1999, Matthew Dillon wrote:
:Hence the NEW flag RFSTACK. Why would this be a bad thing? This would keep
:the old behavior and allow much nicer new behavior. I didn't suggest
:changing the old behavior. This would just greatly simplify things so all of
I think Richard Seaman has it right: the stack needs to be passed.
Why don't we simply implement the linux clone()? It sounds to me that
it would be trivial.
Let's add another parameter to fork1/rfork():
pid_trfork __P((int, ...)); for userland
struct rfork_args { int flags; caddr_t extra; };
and in the kernel would be:
fork1(p1, flags)
register struct proc *p1;
int flags;
caddr_t extra;
{ foo
}
We, of course, have backward binary and code compatibility outside of the
kernel with the ellipses, and inside the kernel we control it anyway so we
can modify whatever needs to be changed.
:the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a
:stack and as soon as the rfork() returned movl newstack,%esp and whatnot,
:wouldn't this be a pretty simple solution?
No, because one of the processes may overrun the stack before the other
one managed to return from rfork(). The child process cannot use the
old stack at all.
Why would a simple movl be using the stack?
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: rfork()
: :the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a : :stack and as soon as the rfork() returned movl newstack,%esp and whatnot, : :wouldn't this be a pretty simple solution? : : No, because one of the processes may overrun the stack before the other : one managed to return from rfork(). The child process cannot use the : old stack at all. : :Why would a simple movl be using the stack? If you are making a subroutine *call* to the rfork() routine, where do you think the return PC address is stored? On the stack. The rfork() routine is going to 'ret' *after* doing the rfork syscall. 'ret' pops the stack. While this in itself is not modifying the stack, you can still wind up with the situation where process A returns from the rfork and then does something else which overwrites the stack before process B has a chance to return from the rfork(). This is why, in my assembly example, I was forced to make the syscall manually rather then call the rfork() library function. : : Brian Feldman _ __ ___ ___ ___ -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rfork()
On Sun, 21 Mar 1999, Matthew Dillon wrote: : :the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a : :stack and as soon as the rfork() returned movl newstack,%esp and whatnot, : :wouldn't this be a pretty simple solution? : : No, because one of the processes may overrun the stack before the other : one managed to return from rfork(). The child process cannot use the : old stack at all. : :Why would a simple movl be using the stack? If you are making a subroutine *call* to the rfork() routine, where do you think the return PC address is stored? On the stack. The rfork() routine is going to 'ret' *after* doing the rfork syscall. 'ret' pops the stack. While this in itself is not modifying the stack, you can still wind up with the situation where process A returns from the rfork and then does something else which overwrites the stack before process B has a chance to return from the rfork(). Why does it matter if something munges the stack in proc A though before proc B returns since proc B is going to immediately switch over to a new stack? This is why, in my assembly example, I was forced to make the syscall manually rather then call the rfork() library function. : : Brian Feldman _ __ ___ ___ ___ -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rfork()
: If you are making a subroutine *call* to the rfork() routine, where : do you think the return PC address is stored? On the stack. The : rfork() routine is going to 'ret' *after* doing the rfork syscall. : 'ret' pops the stack. While this in itself is not modifying the stack, : you can still wind up with the situation where process A returns from : the rfork and then does something else which overwrites the stack before : process B has a chance to return from the rfork(). : :Why does it matter if something munges the stack in proc A though before :proc B returns since proc B is going to immediately switch over to a new :stack? The return address for the procedure call is on the stack. If something munges the stack after the physical rfork occurs but before both processes can return from the rfork() clib function, then one of the processes attempting to return will pop a bogus return address and seg fault. -Matt Matthew Dillon dil...@backplane.com : Brian Feldman _ __ ___ ___ ___ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rfork()
On Sun, 21 Mar 1999, Matthew Dillon wrote: : If you are making a subroutine *call* to the rfork() routine, where : do you think the return PC address is stored? On the stack. The : rfork() routine is going to 'ret' *after* doing the rfork syscall. : 'ret' pops the stack. While this in itself is not modifying the stack, : you can still wind up with the situation where process A returns from : the rfork and then does something else which overwrites the stack before : process B has a chance to return from the rfork(). : :Why does it matter if something munges the stack in proc A though before :proc B returns since proc B is going to immediately switch over to a new :stack? The return address for the procedure call is on the stack. If something munges the stack after the physical rfork occurs but before both processes can return from the rfork() clib function, then one of the processes attempting to return will pop a bogus return address and seg fault. What's to stop the RFSTACK from copying the stack itself into the new stack that is located elsewhere in RAM and attached to the vm space? Actually, rfork() would just set it in the trap frame anyway, so there would be no extra user code to do this. -Matt Matthew Dillon dil...@backplane.com : Brian Feldman _ __ ___ ___ ___ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Confused by wcd-acd in UPDATING
In message 84061.921771...@axl.noc.iafrica.com Sheldon Hearn writes: : 19990316: : The name of the old wd.c and atapi.c based CDROM driver has : been changed back to wcd. So update your config file to use : device wcd instead of device acd. : : Am I right in thinking that this only applies to people who are _not_ : using Soren's new IDE/ATA/ATAPI driver? Yes. You are correct. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NetBoot 3Com card.
I have a couple of 905B 3com cards. I'm interested in running diskless (especially since a harddisk in the one machine just died). After reading the handbook, I found the diskless information to be extreamly outdated. Does netboot now support the 905 line of 3com cards? (Any test drivers out there for it?) No. You might have some success with a commercial bootprom (eg. from www.incom.de) and a tftp'able boot image. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
However Justin's random number comment speaks back to a technique I was working on earlier, where such a number would be secreted in the disklabel of the disk to be booted. This number would have to be generated in a fairly unique fashion (I planned to use the TOD to try to keep it from wrapping), and it'd then be passed in in the environment or as an argument to the kernel. How would that work with netboot or booting from foreign fs, such as FAT? Netbooting is easy, as we can pass an unmabiguous identifier for the remote filesystem to the kernel (the loader and the kernel share the same context on this). Booting from a FAT filesystem isn't a reality until DEVFS arrives, and at that point we have a pile more options available to us again. I wouldn't be too concerned about that just yet. If we restrict ourselves to disklabel-carrying fs, an alternative would be writing the datetime plus a semi-random number (such as time down to ms) on the disklabel of the disk selected, and passing this number to the kernel. [reads what you said again] Unless, of course, that's precisely what you are talking about... Correct. I was looking for a field in the disklabel that I could spam with a suitable number based on the time from the RTC, and I'd then pass that number and the disklabel checksum into the kernel. The only way that this would break would be in the face of tight circumstance and the clock going backwards. However, there's another technique which would work quite well, and one I'm actually moderately enamoured of (modulo it's ability to confuse the heck out of people). Use the last mounted on field to find and mount filesystems. Again, same objections... :-) Same solutions. Plus we'd be likely to place some metadata somewhere on a FAT filesystem, so it'd be trivial to put such a field there. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Correct. I was looking for a field in the disklabel that I could spam with a suitable number based on the time from the RTC, and I'd then There isn't one. Especially when there is no disklabel or a read-only disklabel. Again, same objections... :-) Same solutions. Plus we'd be likely to place some metadata somewhere on a FAT filesystem, so it'd be trivial to put such a field there. Similar objections. Disks should be write protected to inhibit spam :-). I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
- Peripheral driver to device routing Such as ? Such as the ability to have more than one driver share the same device, command generation counts and priority queuing to allow correct 'replay' of overlapped commands when an error occurs, etc. See: http://www.freebsd.org/~gibbs/cam.html That will probably need changes to work with ATA4's tagged queing at least... I just read the ATA5 draft (couldn't find the last ATA4 draft at the wdc website). I don't see any issues here other than the fact that the effect of overlapped commands on data integrity seems to be unspecified. Are they always handled in FIFO order? Can reads be seek optimized? What happens in the case of a queued write after a queued read to the same location? My hope is that, since the spec does not allow you to specify the sorting restrictions on a per request basis as you can in SCSI, FIFO ordering is implied. They even mention that the feature is intended to overlap command processing latency without mentioning the possibility of other optimizations, so perhaps this really is the case. Too bad they didn't just define the two bits necessary (and left as spares in the tag specification register) to allow the same queuing feature set as SCSI. Command queuing was a major factor in why I wrote the CAM code. Solving these issues is not trivial. Agreed, but have you looked at how ATA4 handles queing ?? Yes. - an aplication pass-thru interface Hmm, what for ?? cdrecord, a userland disk format utility, camcontrol functionality, etc. etc. He he, ATAPI dont need cdrecord as all ATAPI burners use the same command set (MMC), where your average SCSI burner has its own propietary command set (well, the ATA/ATAPI guys did get one thing right :) ), Almost all newer SCSI cd burners use MMC now and cdrecord supports MMC devices. Why write another utility if there is already one that speaks the necessary language that our users are familiar with? OK, I'm done discussing this (se my other mail), I'd rater spend my (very limitted) time productively. Fair enough. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Correct. I was looking for a field in the disklabel that I could spam with a suitable number based on the time from the RTC, and I'd then There isn't one. Especially when there is no disklabel or a read-only disklabel. Again, same objections... :-) Same solutions. Plus we'd be likely to place some metadata somewhere on a FAT filesystem, so it'd be trivial to put such a field there. Similar objections. Disks should be write protected to inhibit spam :-). I'm happy to entertain any alternate solutions. I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? I type it into the config file or the command line. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? I type it into the config file or the command line. And you submit that this is an acceptable solution? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
aic
Any hope of the aic driver gracing -current anytime soon? I'm really itching to port my burning software over. Cheers, -- Dan Moschuk (tfreak...@globalserve.net) Senior Systems/Network Administrator Globalserve Communications Inc., a Primus Canada Company If at first you don't succeed, redefine success To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
CPUT_WT_ALLOC_DISABLE
Does anyone want a CPU_WT_ALLOC_DISABLE and CPU_WT_ALLOC_ENABLE as separate options? I see a couple changes that should be made to the kernel now: CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x58c Stepping=12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX There should be another line, formatted the same, that ALWAYS reports CPU_WT_ALLOC info. This will help in debugging problems with certain hardware, because on K6-2's I get unreliability with write allocation on. For instance, I updated my BIOS lately and observed a crash. On boot -v, I noted that the BIOS was kind enough to turn on write allocation, but on a CPU that it doesn't seem to work well on. I propose an option to turn OFF write allocation instead of just one to turn it on. I also propose the change in CPU info printouts to (more correct spacing and extra line): CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-like CPU) Origin = AuthenticAMD Id = 0x58c Stepping = 12 Features = 0x8021bf FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX Write Allocation: Disabled 15-16M Caching Enable: No The changes would be better spacing, a write allocation line (for whatever CPUs are supported, notably the K5, K6, K6-[23]), and changing class to the more sensible like (i.e. a K6 really is 686-class, but being socket 7 is 586-like). Comments? Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Reporting AMD processors (was: CPUT_WT_ALLOC_DISABLE)
On Monday, 22 March 1999 at 0:54:12 +, Brian Feldman wrote: Does anyone want a CPU_WT_ALLOC_DISABLE and CPU_WT_ALLOC_ENABLE as separate options? I see a couple changes that should be made to the kernel now: CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x58c Stepping=12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX There should be another line, formatted the same, that ALWAYS reports CPU_WT_ALLOC info. This will help in debugging problems with certain hardware, because on K6-2's I get unreliability with write allocation on. For instance, I updated my BIOS lately and observed a crash. On boot -v, I noted that the BIOS was kind enough to turn on write allocation, but on a CPU that it doesn't seem to work well on. What's wrong with leaving the message in the -v output? After all, it's debugging info. I propose an option to turn OFF write allocation instead of just one to turn it on. I also propose the change in CPU info printouts to (more correct spacing and extra line): CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-like CPU) Origin = AuthenticAMD Id = 0x58c Stepping = 12 Features = 0x8021bf FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX Write Allocation: Disabled 15-16M Caching Enable: No The changes would be better spacing, a write allocation line (for whatever CPUs are supported, notably the K5, K6, K6-[23]), and changing class to the more sensible like (i.e. a K6 really is 686-class, but being socket 7 is 586-like). You'd better pass the spacing issue past bde. Certainly it mathes the other messages. On the whole, I suppose this is reasonable info, but I wonder if we're not tending towards too much information anyway. I needed to increase the MSGBUF_SIZE on some machines just to get the total content of a non-verbose boot. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? I type it into the config file or the command line. And you submit that this is an acceptable solution? Of course. The FreeBSD device name won't change (modulo implementation bugs), and even when it does, changing the config file is easier than changing /etc/fstab. Note that there is, or should be, no problem here with the BIOS drive number. My example has 1: in it to switch from the default BIOS drive of hard disk 0. The boot blocks should read the config file on the new drive[,slice,partition] to determine the FreeBSD device name (drive and unit number, but not slice or partition). Leave out 1: from my example. Then booting will not be affected by changes in the BIOS drive number. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Reporting AMD processors (was: CPUT_WT_ALLOC_DISABLE)
On Mon, 22 Mar 1999, Greg Lehey wrote: On Monday, 22 March 1999 at 0:54:12 +, Brian Feldman wrote: Does anyone want a CPU_WT_ALLOC_DISABLE and CPU_WT_ALLOC_ENABLE as separate options? I see a couple changes that should be made to the kernel now: CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x58c Stepping=12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX There should be another line, formatted the same, that ALWAYS reports CPU_WT_ALLOC info. This will help in debugging problems with certain hardware, because on K6-2's I get unreliability with write allocation on. For instance, I updated my BIOS lately and observed a crash. On boot -v, I noted that the BIOS was kind enough to turn on write allocation, but on a CPU that it doesn't seem to work well on. What's wrong with leaving the message in the -v output? After all, it's debugging info. What's wrong is that this is info that should really be printed with the rest of the info. When people send PRs with the dmesg it will show what could possibly be wrong, and with this kind of change would show MORE of what could be wrong. I propose an option to turn OFF write allocation instead of just one to turn it on. I also propose the change in CPU info printouts to (more correct spacing and extra line): CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-like CPU) Origin = AuthenticAMD Id = 0x58c Stepping = 12 Features = 0x8021bf FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX Write Allocation: Disabled 15-16M Caching Enable: No The changes would be better spacing, a write allocation line (for whatever CPUs are supported, notably the K5, K6, K6-[23]), and changing class to the more sensible like (i.e. a K6 really is 686-class, but being socket 7 is 586-like). You'd better pass the spacing issue past bde. Certainly it mathes the other messages. On the whole, I suppose this is reasonable info, but I wonder if we're not tending towards too much information anyway. I needed to increase the MSGBUF_SIZE on some machines just to get the total content of a non-verbose boot. Yeah, I remember System 7's boot having about 1-3 lines, I don't recall exactly. But, having enough output is GOOD! Maybe MSGBUF_SIZE should be increased by default nowadays. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
/etc/rc.conf, take 46!
OK, so it seems everyone's found something to like and dislike about
the new scheme. In that regard, it seems pretty much equivalent to
the previous layout when that was first introduced. :)
However, incremental refinement for this stuff has always been the
order of the day, so in that spirit, here's my proposal to deal with
the most recent set of gripes: That rc.conf contains code in
addition to data.
The following diffs make rc.conf a variable-only file, at the cost of
distributing the hook-calling mechanism into all the former clients of
rc.conf. That really doesn't bother me if it doesn't bother you, and
further optimization of it can always be another future incremental
refinement. Another incremental, albeit contraversial, refinement
would be to change /etc/defaults/rc.conf and friends into something
truely machine-parsable, changing statements like this:
if [ -f /some/conf/file ]; then
. /some/conf/file
fi
Into something like this:
if [ -f /some/conf/file ]; then
eval `/sbin/rcvtosh /some/conf/file`
fi
But these changes do not attempt to do that, they simply attempt to
make the existing rc.conf format somewhat easier to parse. Comments
requested.
Index: netstart
===
RCS file: /home/ncvs/src/etc/netstart,v
retrieving revision 1.53
diff -u -u -r1.53 netstart
--- netstart1999/02/10 18:08:16 1.53
+++ netstart1999/03/22 01:54:16
@@ -12,8 +12,11 @@
# If there is a global system configuration file, suck it in.
if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
- . /etc/rc.conf
+ for i in ${rc_conf_files}; do
+ if [ -f $i ]; then
+ . $i
+ fi
+ done
fi
if [ -f /etc/rc.network ]; then
Index: pccard_ether
===
RCS file: /home/ncvs/src/etc/pccard_ether,v
retrieving revision 1.11
diff -u -u -r1.11 pccard_ether
--- pccard_ether1999/02/22 02:55:18 1.11
+++ pccard_ether1999/03/22 01:55:27
@@ -7,11 +7,14 @@
# example: pccard_ether ep0 -link0
#
-# Suck in the configuration variables
+# If there is a global system configuration file, suck it in.
if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
- . /etc/rc.conf
+ for i in ${rc_conf_files}; do
+ if [ -f $i ]; then
+ . $i
+ fi
+ done
fi
if [ x$pccard_ifconfig != xNO ] ; then
Index: rc
===
RCS file: /home/ncvs/src/etc/rc,v
retrieving revision 1.183
diff -u -u -r1.183 rc
--- rc 1999/03/17 04:00:04 1.183
+++ rc 1999/03/22 01:56:24
@@ -33,11 +33,13 @@
fi
# If there is a global system configuration file, suck it in.
-#
if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
- . /etc/rc.conf
+ for i in ${rc_conf_files}; do
+ if [ -f $i ]; then
+ . $i
+ fi
+ done
fi
# Configure ccd devices.
Index: rc.devfs
===
RCS file: /home/ncvs/src/etc/rc.devfs,v
retrieving revision 1.4
diff -u -u -r1.4 rc.devfs
--- rc.devfs1999/02/10 18:08:16 1.4
+++ rc.devfs1999/03/22 01:56:39
@@ -1,11 +1,15 @@
#
# $Id: rc.devfs,v 1.4 1999/02/10 18:08:16 jkh Exp $
#
+
# If there is a global system configuration file, suck it in.
if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
- . /etc/rc.conf
+ for i in ${rc_conf_files}; do
+ if [ -f $i ]; then
+ . $i
+ fi
+ done
fi
# Setup DEVFS, ie permisisons, links etc.
Index: rc.diskless2
===
RCS file: /home/ncvs/src/etc/rc.diskless2,v
retrieving revision 1.2
diff -u -u -r1.2 rc.diskless2
--- rc.diskless21999/02/10 18:08:16 1.2
+++ rc.diskless21999/03/22 01:57:04
@@ -2,11 +2,13 @@
#
# If there is a global system configuration file, suck it in.
-#
if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
- . /etc/rc.conf
+ for i in ${rc_conf_files}; do
+ if [ -f $i ]; then
+ . $i
+ fi
+ done
fi
mount_mfs -s ${var_run_sectors:=2048} -T qp120at dummy /var/run
Index: rc.firewall
===
RCS file: /home/ncvs/src/etc/rc.firewall,v
retrieving revision 1.20
diff -u -u -r1.20 rc.firewall
--- rc.firewall 1999/02/10 18:08:16 1.20
+++ rc.firewall 1999/03/22 01:57:16
@@ -2,11 +2,14 @@
# Setup system for firewall service.
# $Id: rc.firewall,v 1.20
Re: How to add a new bootdevice to the new boot code ???
I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? I type it into the config file or the command line. And you submit that this is an acceptable solution? Of course. The FreeBSD device name won't change (modulo implementation bugs), and even when it does, changing the config file is easier than changing /etc/fstab. Since this entire thread came about due to a device name change, and given that the last major upheaval in this domain was over a similar change, I'd say that was wishful thinking in the least. Note that there is, or should be, no problem here with the BIOS drive number. My example has 1: in it to switch from the default BIOS drive of hard disk 0. The boot blocks should read the config file on the new drive[,slice,partition] to determine the FreeBSD device name (drive and unit number, but not slice or partition). Leave out 1: from my example. Then booting will not be affected by changes in the BIOS drive number. This presupposes that the configuration file is always right, ie. that it correctly describes the location of the disk. This isn't really a valid premise, and in any case does no better than to duplicate the 'last mounted on' field in the filesystem itself. I'm not sold, sorry. This isn't sufficiently automatable, nor does it remove the room for massive user error that I for one fear greatly. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
And you submit that this is an acceptable solution? Of course. The FreeBSD device name won't change (modulo implementation bugs), and even when it does, changing the config file is easier than changing /etc/fstab. Since this entire thread came about due to a device name change, and given that the last major upheaval in this domain was over a similar change, I'd say that was wishful thinking in the least. Driver name changes are implementation bugs. So are driver numbering changes. The latter are more serious, since you can't work around them by linking files in /dev if the new or old numbering is dynamic. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
!!!!
subscribe freebsd-current To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: /etc/rc.conf, take 46!
On 22-Mar-99 Jordan K. Hubbard wrote:
OK, so it seems everyone's found something to like and dislike about
the new scheme. In that regard, it seems pretty much equivalent to
the previous layout when that was first introduced. :)
If it makes you feel any better, I kind of like the new system with the default
setup in /etc/defaults and the customizations/overrides in /etc. Makes perfect
sense to me and works well.
I don't really care where the functionality of sucking in the configuration
files is, but the obvious point seems to be that having the code duplicated in
about six different places will make maintaining it a pain. Maybe a compromise
would be to include a function in /etc/defaults/rc.conf that is called
everywhere else so that at least you only have to change one function. IOW,
/etc/defaults/rc.conf have:
suck_in_files()
{
for i in ${rc_conf_files}; do
if [ -f $i ]; then
. $i
fi
done
}
And just have all the various files you had to patch below do the following:
if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
suck_in_files
fi
I guess it's still including code in /etc/rc.conf, but it doesn't execute
it. So, if Joe Schmoe copies /etc/defaults/rc.conf to /etc/rc.conf it will
still work. Actually, after some testing, this can be broken. If
suck_in_files() is redefined in the included files there are weird side
effects, ranging from seg faults to working properly to the function changing
mid-stream. Then you could I suppose define _another_ file in /etc or
/etc/defaults that defined suck_in_files() and other similar functions so that
the if-statement above would become:
if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
. /etc/defaults/rc.functions
suck_in_files
fi
Bleah.. Why can't we assume users can read and hold them accountable to that?
At the very beginning of /etc/defaults/rc.conf it tells them that they shouldn't
copy it to /etc/rc.conf. If they are too stubborn to do as they are told,
they should either a) be using /stand/sysinstall, or b) be willing to accept
the consequences.
---
John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/
PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: rfork()
Matthew Dillon wrote: :Hence the NEW flag RFSTACK. Why would this be a bad thing? This would keep :the old behavior and allow much nicer new behavior. I didn't suggest :changing the old behavior. This would just greatly simplify things so all of I think Richard Seaman has it right: the stack needs to be passed. Why don't we simply implement the linux clone()? It sounds to me that it would be trivial. Doing clone() in libc that calls rfork(2) and doing all the stack setup should be pretty easy.. (Richard has done it already, yes?) On the other hand, the linux emulator needs it so there's a counter-argument for making it a proper syscall outright. Leaving the rfork(2) stuff unmolested and at least resembling it's plan9 origins probably has some merit - adding extra arguments would mess that up. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
syslogd meets The Sorcerer's Apprentice
I'd like to add safeguards to keep syslogd from cascading its own error messages. To describe more fully: I just came back from a weekend getaway and discovered my crash box screaming bloody murder. I haven't had any odd experiments running for quite some time now. A quick look at the top of /var/log/messages.0 showed: Mar 18 00:00:00 detlev newsyslog[543]: logfile turned over Mar 21 15:44:25 detlev syslogd: /dev/ttyv1: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyv2: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp0: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp2: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp3: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/console: Too many open files in system: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyv1: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyv2: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp0: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp2: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp3: Too many open files in system Mar 21 15:44:25 detlev /kernel: file: table is full Mar 21 15:44:25 detlev last message repeated 41 times Mar 21 15:44:25 detlev sendmail[17482]: PAA17481: SYSERR(UID0): Can't create transcript file xfPAA17482: Too many open files in system Mar 21 15:44:25 detlev sendmail[17482]: PAA17481: SYSERR(UID0): Can't open /dev/null: Too many open files in system Mar 21 15:44:26 detlev syslogd: /var/run/utmp: Too many open files in system Mar 21 15:44:26 detlev syslogd: /var/run/utmp: Too many open files in system Mar 21 15:44:26 detlev /kernel: file: table is full Mar 21 15:44:26 detlev syslogd: /var/run/utmp: Too many open files in system Mar 21 15:44:26 detlev last message repeated 3 times Mar 21 15:44:26 detlev /kernel: file: table is full Mar 21 15:44:26 detlev syslogd: /var/run/utmp: Too many open files in system Mar 21 15:44:26 detlev last message repeated 3 times After that it settled down to just repeating: Mar 21 15:45:30 detlev syslogd: /dev/ttyv1: Too many open files in system Mar 21 15:45:30 detlev syslogd: /dev/ttyv2: Too many open files in system Mar 21 15:45:30 detlev syslogd: /dev/ttyp0: Too many open files in system Mar 21 15:45:30 detlev syslogd: /dev/ttyp2: Too many open files in system Mar 21 15:45:30 detlev syslogd: /dev/ttyp3: Too many open files in system Mar 21 15:45:30 detlev /kernel: file: table is full Evidently it was recording about 125 log messages per second. I came home to discover a full /var, a 25 MB uncompressed messages.0, no /var/log/messages at all, and overall a fairly unhappy computer. (Evidently, when newsyslog ran, things were already hosed. It could move messages.0, but not gzip it or create /var/log/messages.) This is all from a March 13 build, I believe, if it matters. MAXUSERS is set to 20, and there were probably six logins including a small X session at the time. All had been idle for hours. (I figure something was leaking fd's bad.) Now, I don't know what set this off. I moved the messages.0 to another filesystem, rebooted, recreated /var/log/messages, and restarted syslogd. Like I say, I don't know what set this off. That's once concern, but will take more investigation. My concern is whether we should keep syslogd from going into Sorcerer's Apprentice mode like this. What do you think about adding safeguards against syslogd logging more than, say, thirty messages per hour saying why can't log messages? Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /etc/rc.conf, take 46!
The problem with putting code in /etc/defaults/rc.conf is that
simplistic parsers which read it as ``var = value # optional comment''
get very confused by for loops or function declarations or what have
you. It also makes it more difficult to read in /etc/{*,.}rc.conf
from an admin program, permute it in some way, and then write out a
whole new config file - you have to detect the meta-information
somehow and preserve it across saves in addition to just parsing
variables (which is more straight-forward to say the least).
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: rfork()
: :proc B returns since proc B is going to immediately switch over to a new : :stack? : : The return address for the procedure call is on the stack. If something : munges the stack after the physical rfork occurs but before both processes : can return from the rfork() clib function, then one of the processes : attempting to return will pop a bogus return address and seg fault. : :What's to stop the RFSTACK from copying the stack itself into the new stack :that is located elsewhere in RAM and attached to the vm space? Actually, :rfork() would just set it in the trap frame anyway, so there would be no :extra user code to do this. Why make rfork() a thousand times slower when performance is almost certainly an issue for the people using it? Since the one of the big points of using rfork() the way we are using it is to avoid copying pagetables, descriptor tables, and so forth, we sure don't want to add any back in! : : Brian Feldman_ __ ___ ___ ___ : : Brian Feldman _ __ ___ ___ ___ -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
