Re: How to add a new bootdevice to the new boot code ???
In article 199903171205.naa25...@freebsd.dk you wrote: It seems David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? Not if I can help it :) It could be done by slamming a translation layer ontop of the existing wd driver or of cause on top of the new I'm doing, but all it adds is overhead, both performance wise and codesize wise. There is nothing that prohibits having both of cause, but it is not a priority for me to add more complexity into the picture before everything else is done. 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 - Peripheral driver to device routing - debugging/tracing facilities - an extensible error recovery framework - an understanding of command queuing (also relevant for ATAPI) - understanding of hot plug events - an aplication pass-thru interface The question about translation layers is secondary and I would likely choose to not introduce a translation at all. Issuing pure ATAPI commands to atapi devices at the peripheral driver level is somthing that CAM could easily do. I would probably choose to merge ATAPI functionality into the da driver to avoid duplicated code and to ensure that bug fixes only need to be performed in one place. After all, the machinery for talking to an ATAPI or SCSI disk is very similar (If the disk says it needs to be spun up, spin it up; if we have too many transactions outstanding and fear tag starvation, send an ordered tag; when we close the disk or panic, synchronize its cache to stable media; etc. etc.) even if the command op codes and format are slightly different. But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. -- 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 ???
In article 199903171103.naa13...@ceia.nordier.com you wrote: Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. Why not have the boot blocks pass in a device 'name' rather than a major number. If the goal is to ditch major numbers entirely with a properly working DEVFS, then using major numbers in the new boot loader seems to be the wrong way to go. Until DEVFS is a reality, the kernel will still need to perform a name to major number translation, but it should be left up to the kernel. Because there's no way to work out a name either. If I explicitly say: 1:foobar(0,a)/kernel there certainly is a way to work out the name. Perhaps in the autoboot case you'll have to guess, but it would be nice if the current boot mechanism allowed user intervention as a way to boot a kernel with an unknown bdev. All the loader has to go on is the BIOS unit number and the disklabel, the latter of which can't be relied on to be up-to-date (ie. it reflects what the disk was when it was laid out, not what some nominal kernel is going to call it). Well, the disklabel format should be revamped so that we can tag devices in a unique fashion (user's pet name for the partition plus a 128bit random number perhaps). This would allow the boot loader to alway tell the kernel unambiguously how to find the root device. It would also allow us to ensure that the attach order for all devices with a BSD label matched the BIOS probe order. I would also love to be able to mount volumes by the name that I've picked for them rather than by device node too - it would practically eliminate the need for hard wiring of devices. -- 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 ???
It seems Justin T. Gibbs wrote: In article 199903171205.naa25...@freebsd.dk you wrote: It seems David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? Not if I can help it :) It could be done by slamming a translation layer ontop of the existing wd driver or of cause on top of the new I'm doing, but all it adds is overhead, both performance wise and codesize wise. There is nothing that prohibits having both of cause, but it is not a priority for me to add more complexity into the picture before everything else is done. 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. - Peripheral driver to device routing Such as ? - debugging/tracing facilities Well, there is a little of that allready, more to come. - 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. - an understanding of command queuing (also relevant for ATAPI) Hmm, well, yes, but I'm not sure that what ATA/ATAPI has to offer here is comaptible with the CAM framwork. I plan to support tagged queueing on ATA disks though. - understanding of hot plug events This really isn't an issue on ATA/ATAPI devices in most cases, but in the mobile world there is a need for this, but that is already being worked on. We need alot of work in other places in the kernel, before this can be really utilized though. - an aplication pass-thru interface Hmm, what for ?? ATAPI commands could esily be passed through, but I'd like a driver to be in charge here, and besides we allready have drivers for most existing ATAPI HW. The question about translation layers is secondary and I would likely choose to not introduce a translation at all. Issuing pure ATAPI commands to atapi devices at the peripheral driver level is somthing that CAM could easily do. I would probably choose to merge ATAPI functionality into the da driver to avoid duplicated code and to ensure that bug fixes only need to be performed in one place. ATAPI has nothing to do in the da driver, well maybe for ZIP/LS120 drives, but disks are ATA, and that needs translation. After all, the machinery for talking to an ATAPI or SCSI disk is very similar (If the disk says it needs to be spun up, spin it up; if we have too many transactions outstanding and fear tag starvation, send an ordered tag; when we close the disk or panic, synchronize its cache to stable media; etc. etc.) even if the command op codes and format are slightly different. Thats correct, but there is enough differences that it still is a pain. But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. Right :) -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: In article 199903171103.naa13...@ceia.nordier.com you wrote: Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. Why not have the boot blocks pass in a device 'name' rather than a major number. If the goal is to ditch major numbers entirely with a properly working DEVFS, then using major numbers in the new boot loader seems to be the wrong way to go. Until DEVFS is a reality, the kernel will still need to perform a name to major number translation, but it should be left up to the kernel. Because there's no way to work out a name either. If I explicitly say: 1:foobar(0,a)/kernel there certainly is a way to work out the name. Perhaps in the autoboot case you'll have to guess, but it would be nice if the current boot mechanism allowed user intervention as a way to boot a kernel with an unknown bdev. YES!! can we please have that ?? -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 ???
Søren Schmidt wrote:
It seems Justin T. Gibbs wrote:
Why not have the boot blocks pass in a device 'name' rather than a
major number. If the goal is to ditch major numbers entirely with
a properly working DEVFS, then using major numbers in the new boot
loader seems to be the wrong way to go. Until DEVFS is a reality,
the kernel will still need to perform a name to major number translation,
but it should be left up to the kernel.
Because there's no way to work out a name either.
If I explicitly say:
1:foobar(0,a)/kernel
there certainly is a way to work out the name. Perhaps in the autoboot
case you'll have to guess, but it would be nice if the current boot
mechanism allowed user intervention as a way to boot a kernel with an
unknown bdev.
YES!! can we please have that ??
Until DEVFS is a reality, I think it makes sense to not break
compatibility with the existing boot interface.
What Justin suggests seems good, but why not postpone the big change
till the user has compelling reasons (like a working DEVFS) for
making it, and losing ability to (a) boot 2.x and 3.x kernels; (b)
use his existing bootblocks; and (c) use his existing netboot and
other external (fbsdboot.exe-like) programs?
For the short term, I'd suggest modifying the bootblocks to optionally
accept an arbitrary major# in place of a {wd, da, ad, fd, ...}
string
1:42(0,a)/kernel
since that can easily be accommodated by the existing arguments
passed to the kernel.
While not an optimal solution, this does have the virtue of adding
the ability to boot from any device not specifically provided for,
and without requiring customization of the bootblocks (or any more
work on the kernel than is presently required to add a device
driver).
--
Robert Nordier
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 ???
Bob Willcox wrote: I have an LS-120 and I'd be happy to test the new boot code with it. Bob Thanks very much. I'll contact you and Andrzej when the changes are made. -- Robert Nordier 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 ???
Soren Schmidt wrote: It seems Justin T. Gibbs wrote: In article 199903171205.naa25...@freebsd.dk you wrote: It seems David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple . Does this mean ata disks won't come under CAM/da ? Not if I can help it :) It could be done by slamming a translation layer ontop of the existing wd driver or of cause on top of the new I'm doing, but all it adds is overhead, both performance wise and codesize wise. There is nothing that prohibits having both of cause, but it is not a priority for me to add more complexity into the picture before everything else is done. 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. Exactly.. why reinvent it? It seems a little silly to reinvent the other stuff that cam provides that the ata[pi] driver hasn't finished yet. The question about translation layers is secondary and I would likely choose to not introduce a translation at all. Issuing pure ATAPI commands to atapi devices at the peripheral driver level is somthing that CAM could easily do. I would probably choose to merge ATAPI functionality into the da driver to avoid duplicated code and to ensure that bug fixes only need to be performed in one place. ATAPI has nothing to do in the da driver, well maybe for ZIP/LS120 drives, but disks are ATA, and that needs translation. Yes, we know that IDE disks are ATA and not ATAPI, but the cam layer does have a lot of flexibility for dealing with differences even as large as that. You don't really need ``translation'' as such since a lot of the specifics are done by the backend driver and are a black box as far as the higher layers are concerned. You basically get to define the interface between cam and the drivers at your convenience. While the da, cd etc upper level drivers do have scsi specific stuff in them (they are in the scsi subdir after all), they largely deal with generic CCB's (CAM Control Blocks) and send special scsi commands as required. Obviously these would need changing so they can send ATA or ATAPI commands instead. After all, the machinery for talking to an ATAPI or SCSI disk is very similar (If the disk says it needs to be spun up, spin it up; if we have too many transactions outstanding and fear tag starvation, send an ordered tag; when we close the disk or panic, synchronize its cache to stable media; etc. etc.) even if the command op codes and format are slightly different. Thats correct, but there is enough differences that it still is a pain. You shouldn't ever have to translate a scsi CCB or SCSI command code into an ATAPI command or ATA command. A correctly functioning system would be sending the ata/atapi backend the in a form suitable for being used directly. But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. Right :) Yes. Actually, the biggest problem wouldn't be building an ATA/ATAPI set of frontends and backends around the CAM system, I suspect it would be far harder to finish the generalization of the CAM code. There appear to be a lot of SCSI-specific things lurking in the cam* code... Things like the quirks table referring to T_DIRECT etc (which is from scsi/scsi_all.h) and so on. I half suspect that what Justin had in mind at some point was a set of common code that is either #ifdef'ed or otherwise preprocessed to produce a standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system. This would have the advantage of having all the common code together in one place and shared, while at compile time it built two seperate subsystems that were compiled specifically for the target peripheral bus with definitions to suit each so that translation was never used. -Soren Cheers, -Peter 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 half suspect that what Justin had in mind at some point was a set of common code that is either #ifdef'ed or otherwise preprocessed to produce a standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system. I .75 suspect that such a marriage would be caused by the second systems syndrome and carry no tangible benefits at the end of the day. I respect CAM, it seems to work out great. It also looks like sos driver does what it should so far. I don't see much point in merging the two for the benefits suggested so far. In particular I don't want to see sos and justin spend a lot of time haggeling over the issues for the rather meagre benefits cited so far. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IPSEC support?
Steven P. Donegan wrote: Is there any IPSEC support available for current? I've found support for 2.2.8, but not so far for current. There is support for 3.1-REL. Work is being done for -current, I believe. Keep an eye on http://www.r4k.net/ipsec Alex -- ++---+ | SMTP: ale...@funk.org | E-Gold: 101979 | | ICBM: N52 22.647' E4 51.555' | PGP: 0x1d512a3f | ++---+ 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 half suspect that what Justin had in mind at some point was a set of common code that is either #ifdef'ed or otherwise preprocessed to produce a standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system. This would have the advantage of having all the common code together in one place and shared, while at compile time it built two seperate subsystems that were compiled specifically for the target peripheral bus with definitions to suit each so that translation was never used. The plan has always been to migrate the SCSI knowledge in the XPT layer into a 'personality' module leaving the generic portions of the CAM XPT intact. The personalities would be compiled in using the atapibus0 and scbus0 keywords in config. I don't think it would be that hard, but it would require time I don't have right now. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panics while reading Solaris CDROM
David O'Brien obr...@nuxi.com writes: The core files from the panic seem to be useless -- I can't get anything useful out of ``where'' with a kernel w/debugging symbols: Link CD9660 support statically, instead of using the KLD module. 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
reproducable panic?
I seem to be able to reproduce a panic on my 4.0 machine (updated
yesterday, kernel and world, also could crash with a somewhat older
build)
I have pseudo-device vn and nfs in my kernel, not as a module.
When I vnconfig -c /dev/vn0c /nfsmountpoint/somefile, the system panics
reliably.
If there is more useful info I could give, or shell accounts, etc,
please let me know.
IdlePTD 3133440
initial pcb at 2701d8
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xff68
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01af522
stack pointer = 0x10:0xc0252770
frame pointer = 0x10:0xc0252770
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask =
trap number = 12
panic: page fault
syncing disks...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x30
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01d99b0
stack pointer = 0x10:0xc02524cc
frame pointer = 0x10:0xc02524d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = bio
trap number = 12
panic: page fault
dumping to dev 20401, offset 393216
dump 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43
42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19
18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:287
#1 0xc01486ed in panic (fmt=0xc024aad7 page fault)
at ../../kern/kern_shutdown.c:448
#2 0xc0210016 in trap_fatal (frame=0xc0252490, eva=48)
at ../../i386/i386/trap.c:943
#3 0xc020fccf in trap_pfault (frame=0xc0252490, usermode=0, eva=48)
at ../../i386/i386/trap.c:836
#4 0xc020f902 in trap (frame={tf_es = -1071316976, tf_ds = -1071710192,
tf_edi = -1062680960, tf_esi = 0, tf_ebp = -1071307568,
tf_isp = -1071307592, tf_ebx = -1071245808, tf_edx = -1073217472,
tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071801936, tf_cs = 8, tf_eflags = 66178,
tf_esp = -1036656256, tf_ss = -1071307536}) at
../../i386/i386/trap.c:438
#5 0xc01d99b0 in acquire_lock (lk=0xc0261610)
at ../../ufs/ffs/ffs_softdep.c:267
#6 0xc01dc827 in initiate_write_inodeblock (inodedep=0xc0a8c680,
bp=0xc1e8f398) at ../../ufs/ffs/ffs_softdep.c:2827
#7 0xc01dc5cf in softdep_disk_io_initiation (bp=0xc1e8f398)
at ../../ufs/ffs/ffs_softdep.c:2686
#8 0xc017992a in spec_strategy (ap=0xc0252550)
at ../../miscfs/specfs/spec_vnops.c:555
#9 0xc01790bd in spec_vnoperate (ap=0xc0252550)
at ../../miscfs/specfs/spec_vnops.c:129
#10 0xc01e7af5 in ufs_vnoperatespec (ap=0xc0252550)
at ../../ufs/ufs/ufs_vnops.c:2327
#11 0xc0166a67 in bwrite (bp=0xc1e8f398) at vnode_if.h:891
#12 0xc016b1f6 in vop_stdbwrite (ap=0xc02525b8) at
../../kern/vfs_default.c:297
#13 0xc016b041 in vop_defaultop (ap=0xc02525b8) at
../../kern/vfs_default.c:131
#14 0xc01790bd in spec_vnoperate (ap=0xc02525b8)
at ../../miscfs/specfs/spec_vnops.c:129
#15 0xc01e7af5 in ufs_vnoperatespec (ap=0xc02525b8)
at ../../ufs/ufs/ufs_vnops.c:2327
#16 0xc01674c7 in vfs_bio_awrite (bp=0xc1e8f398) at vnode_if.h:1145
#17 0xc01e1b46 in ffs_fsync (ap=0xc0252640) at
../../ufs/ffs/ffs_vnops.c:205
#18 0xc01dffe7 in ffs_sync (mp=0xc0a04a00, waitfor=2, cred=0xc0a1ff00,
p=0xc028c8e0) at vnode_if.h:499
#19 0xc016fc2b in sync (p=0xc028c8e0, uap=0x0) at
../../kern/vfs_syscalls.c:542
#20 0xc0148299 in boot (howto=256) at ../../kern/kern_shutdown.c:205
#21 0xc01486ed in panic (fmt=0xc024aad7 page fault)
at ../../kern/kern_shutdown.c:448
#22 0xc0210016 in trap_fatal (frame=0xc0252734, eva=4294967144)
at ../../i386/i386/trap.c:943
#23 0xc020fccf in trap_pfault (frame=0xc0252734, usermode=0,
eva=4294967144)
at ../../i386/i386/trap.c:836
#24 0xc020f902 in trap (frame={tf_es = -989003760, tf_ds = 528089104,
tf_edi = -1073741824, tf_esi = -982050144, tf_ebp = -1071306896,
tf_isp = -1071306916, tf_ebx = -1062665024, tf_edx = -152,
tf_ecx = -982050144, tf_eax = -2147483648, tf_trapno = 12, tf_err
= 0,
tf_eip = -1071975134, tf_cs = 8, tf_eflags = 66182,
tf_esp = -1071306860, tf_ss = -1071975907}) at
../../i386/i386/trap.c:438
#25 0xc01af522 in nfs_sigintr (nmp=0xc5771aa0, rep=0xc0a904c0,
p=0xc0133634)
at ../../nfs/nfs_socket.c:1479
#26 0xc01af21d in nfs_timer (arg=0x0) at ../../nfs/nfs_socket.c:1355
#27 0xc014cb8e in softclock
RE: unable to use cdrecord on an ATAPI CD-R under 2.2.8.
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. Now my question is, and this is why I'm cc:ing this to -current is, has this particular problem been addressed in the current release(s) of FreeBSD. The thread that addressed this particular issue (in -current) was about 5 months old. Incase anyone was interested the URL to that thread is.. http://www.freebsd.org/cgi/getmsg.cgi?fetch=1249191+1251848+/usr/local/www/d b/text/1998/freebsd-current/19981108.freebsd-current Thanks again, guess I'll be putting the burner back in the winblowz 98 machine unless someone can help me out with a fix. -Chris -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-questi...@freebsd.org]on Behalf Of Christopher J. Michaels Sent: Saturday, March 20, 1999 9:57 AM To: FreeBSD Mailing List (E-mail) Subject: unable to use cdrecord on an ATAPI CD-R under 2.2.8. Hello, I'm trying to use my ATAPI cd-r on my 2.2.8 box and am having no success at all. I have the acd device in my kernel and it detects just fine upone startup. And I can mount /dev/wcd0c just fine. acd0: drive speed 1377KB/sec, 2048KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: supported write types: CD-R, test write acd0: Audio: play, 2 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked I have tried to use the cdrecord's -scanbus option to try and get starting and what I get is the following... Cdrecord release 1.6.1 Copyright (C) 1995-1998 Jörg Schilling cdrecord: No such file or directory. Cannot open SCSI driver. Ok, it uses /dev/scgx, so I did 'ln -s /dev/rcd0.ctl /dev/scgx' and I still get the above error. So NOW i'm trying to specify the device name on the command line, as it says on the man page I can do. 'cdrecord -scanbus dev=/dev/rcd0.ctl:0,4,0' Cdrecord release 1.6.1 Copyright (C) 1995-1998 Jörg Schilling scsidev: '/dev/rcd0.ctl:0,4,0' devname: '/dev/rcd0.ctl' scsibus: 0 target: 4 lun: 0 cdrecord: Device not configured. Cannot open SCSI driver. If i try similar things such as /dev/rcd0a, /dev/rcd0c, I get the same above error. I've tried MAKEDEV wcd0, acd0, rcd0. With no luck.. MAKEDEV doesn't even recognize acd0. SO, I'm out of ideas, I know others out there are using this thing because I see enough traffic on the mailing list. But does anyone out there know how to help me with this issue? -Chris 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: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: there certainly is a way to work out the name. Perhaps in the autoboot case you'll have to guess, but it would be nice if the current boot mechanism allowed user intervention as a way to boot a kernel with an unknown bdev. YES!! can we please have that ?? As I said before, loader can pass arbitrary parameters to the kernel. I did not answer to the jab you replied with before because I was waiting for Mike's comments. In any case, all environment strings defined in the loader are (for now) copied so kernel can use them. Pick a name, and DTRT in the kernel. Alternatively, arguments to either boot or load kernel commands are passed on to the kernel. Again, it's just a matter of you using it. The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. (I can send this patch to you as soon as you answer to my message concerning the problems I'm having with the ad stuff... :) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: fd broken [!!!]
It's been a couple more weeks, anyone now know why fd(4) is broken? It's really not a good thing :( Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ On Tue, 9 Mar 1999, Brian Feldman wrote: On Sat, 6 Mar 1999, Thomas Dean wrote: So Does anyone have an idea why the hell fd(4) broke?! I have the same problem on 4.0-current SMP of Mon Feb 15 03:34:29 PST 1999. tomdean 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 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panics while reading Solaris CDROM
The core files from the panic seem to be useless -- I can't get anything useful out of ``where'' with a kernel w/debugging symbols: Link CD9660 support statically, instead of using the KLD module. First thing I tried. :-) Bruce's vfs_bio.c fix was the trick. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: reproducable panic?
:I seem to be able to reproduce a panic on my 4.0 machine (updated :yesterday, kernel and world, also could crash with a somewhat older :build) : :I have pseudo-device vn and nfs in my kernel, not as a module. : :When I vnconfig -c /dev/vn0c /nfsmountpoint/somefile, the system panics :reliably. : :If there is more useful info I could give, or shell accounts, etc, :please let me know. test2:/home/dillon# ls -la /var/tmp/ff/test -rw-r--r-- 1 root wheel 33554432 Mar 20 09:01 /var/tmp/ff/test test2:/home/dillon# vnconfig -c /dev/vn2c /var/tmp/ff/test test2:/home/dillon# df apollo:/images/remote.src 1397423 970331 31529975%/var/tmp/ff Works for me. If you have the latest updated yesterday you should be in good shape. See if you can narrow down why it is crashing... try different file sizes for your /nfsmountpoint/somefile, and so forth. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: fd broken [!!!]
I submitted a PR. This is not a show-stopper. I have a system running 2.2.7. fd works on that one. So, I read/write floppies there. It is a pain, though. tomdean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: reproducable panic?
Ok I've been playing around a bit, an iso sized file (500-600mb) seems to trigger it, and a quite small file seemed to do it too but I forgot which one, but just now I made a one byte file and vnconfig'ed it and that paniced. Please try that if you can :) btw I tried a 32mb file like you, also a 16mb one, and neither made it crash. Thanks On Sat, 20 Mar 1999, Matthew Dillon wrote: :I seem to be able to reproduce a panic on my 4.0 machine (updated :yesterday, kernel and world, also could crash with a somewhat older :build) : :I have pseudo-device vn and nfs in my kernel, not as a module. : :When I vnconfig -c /dev/vn0c /nfsmountpoint/somefile, the system panics :reliably. : :If there is more useful info I could give, or shell accounts, etc, :please let me know. test2:/home/dillon# ls -la /var/tmp/ff/test -rw-r--r-- 1 root wheel 33554432 Mar 20 09:01 /var/tmp/ff/test test2:/home/dillon# vnconfig -c /dev/vn2c /var/tmp/ff/test test2:/home/dillon# df apollo:/images/remote.src 1397423 970331 31529975%/var/tmp/ff Works for me. If you have the latest updated yesterday you should be in good shape. See if you can narrow down why it is crashing... try different file sizes for your /nfsmountpoint/somefile, and so forth. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current 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: fd broken [!!!]
Aye, and my LS-120 works great too :) So, que sera sera. Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ On Sat, 20 Mar 1999, Thomas Dean wrote: I submitted a PR. This is not a show-stopper. I have a system running 2.2.7. fd works on that one. So, I read/write floppies there. It is a pain, though. tomdean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current 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: How to add a new bootdevice to the new boot code ???
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( 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. 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. -- \\ 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 ???
The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. Correct. I'm currently leaning heavily towards a tunable which can be set to explicitly control the device the root filesystem is loaded from, eg. set kern.rootdev.device=da0s1a 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. Bruce really doesn't like the environment, preferring instead arguments to modules. This breaks down as soon as you try to set things automatically (which module needs which arguments?) or load things automatically as a result of dependancies (how do you pass arguments to something that's loaded invisibly?). So in this case the code would set kern.rootdev.brand to the magic number, and the kernel would then search for it. 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. -- \\ 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 ???
The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. Correct. I'm currently leaning heavily towards a tunable which can be set to explicitly control the device the root filesystem is loaded from, eg. set kern.rootdev.device=da0s1a How hard would it be to have /boot/loader get the major number from the filesystem itself? Just have it read the node entry for /dev/$rootdev (or similiar). -- David Cross 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 ???
Mike Smith wrote: The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. Correct. On both accounts, I suppose... :-) 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? 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... :-) I'm not sure if you are talking about a pre-generated label, or one written at boot time. It all rests on the meaning of TOD (tentatively translated as Time Of Day... :). 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... :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! 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 ???
The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. Correct. I'm currently leaning heavily towards a tunable which can be set to explicitly control the device the root filesystem is loaded from, eg. set kern.rootdev.device=da0s1a How hard would it be to have /boot/loader get the major number from the filesystem itself? Just have it read the node entry for /dev/$rootdev (or similiar). This doesn't solve the BIOS : FreeBSD unit numbering problem, unfortunately, and it would make moving from one driver to another very difficult (you'd have to override the search). It's a neat idea and one I hadn't thought of, but it doesn't solve enough of the problem. -- \\ 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
broken world
Hi! For a couple weeks for now i have a broken world with following reason: === usr.sbin/i4b/isdnd cc -O -pipe -I/usr/src/usr.sbin/i4b/isdnd/../isdnmonitor -I/usr/src/usr.sbin/i4b/isdnd/../isdntel -I/usr/obj/usr/src/usr.sbin/i4b/isdnd -DDEBUG -DUSE_RTPRIO -DUSE_CURSES -I/usr/obj/usr/src/tmp/usr/include -c rc_scan.c /usr/src/usr.sbin/i4b/isdnd/rc_scan.l: In function `yylex': /usr/src/usr.sbin/i4b/isdnd/rc_scan.l:95: `BEEPCONNECT' undeclared (first use this function) /usr/src/usr.sbin/i4b/isdnd/rc_scan.l:95: (Each undeclared identifier is reported only once /usr/src/usr.sbin/i4b/isdnd/rc_scan.l:95: for each function it appears in.) /usr/src/usr.sbin/i4b/isdnd/rc_scan.l:111: `IDLE_ALG_OUT' undeclared (first use this function) *** Error code 1 Cleaning obj tree doesn't helps. Nothing helps, so. Anybody have similar problems? Adios, /KONG To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Possible fix for rc.conf
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.
Scot
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Possible fix for rc.conf
Scot W. Hetzel hetz...@westbend.net writes: if [ $0 != $i ]; then A more generic fix is for each script to set an environment variable, and check to make sure that variable was not set already. Analogous to how C include files prevent recursive inclusion. -- Rahul Dhesi dh...@spams.r.us.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 ???
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. - 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 for the start of a discussion of these features and why transaction routing was implemented this way. - debugging/tracing facilities Well, there is a little of that allready, more to come. Right. Its duplicated functionality. - 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. - an understanding of command queuing (also relevant for ATAPI) Hmm, well, yes, but I'm not sure that what ATA/ATAPI has to offer here is comaptible with the CAM framwork. I plan to support tagged queueing on ATA disks though. CAM only knows that multiple commands may be outstanding at a time and that they must be marked with serial numbers for proper replay when an error occurs. The specifics of how multiple transactions are specified is something that can be completely isolated into the 'personality' module and as a protocol between the peripheral drivers and the controller drivers. - understanding of hot plug events This really isn't an issue on ATA/ATAPI devices in most cases, but in the mobile world there is a need for this, but that is already being worked on. We need alot of work in other places in the kernel, before this can be really utilized though. So why invent a new notification and cleanup strategy when the CAM one has already been developed and tested in the SCSI world? - an aplication pass-thru interface Hmm, what for ?? cdrecord, a userland disk format utility, camcontrol functionality, etc. etc. ATAPI commands could esily be passed through, but I'd like a driver to be in charge here, and besides we allready have drivers for most existing ATAPI HW. The pass-thru driver is in charge in the CAM world. Is this not sufficient? Sure, there needs to be locking primitives so that drivers competing for the same device do not step on each others toes, but this is already specified by CAM and should be only a day or so of effort to implement. ATAPI has nothing to do in the da driver, well maybe for ZIP/LS120 drives, but disks are ATA, and that needs translation. Why does it need translation? Why not simply issue ATA commands right through the CAM Transport layer. Perhaps you use a function table in your peripheral driver to build the right CAM Control Blocks to send for a particular device. Perhaps you have a completely different peripheral driver for ATA and SCSI devices. That is up to the implementor. My choice would be to have one peripheral driver here, but CAM doesn't tie your hands one way or the other. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
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?) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Possible fix for rc.conf
On Sat, 20 Mar 1999, Scot W. Hetzel wrote: 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. Oh it's too late for that. :) - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
rfork()
Hello,
This was posted to freebsd-questions with no reply.
I tried this and the child process created a core file.
I also tried the other options and they seem to work.
Just RFPROC and RFMEM DON'T!
Thanks,
Michael Mercer
Can any one suggest how to use rfork( RFPROC | RFMEM );
according to the manual, freeBSD supports this and it should create a
new process
which will share the address space.
But what I'm getting is
a) It returns only to the parent process with a childID.
b) It doesn't go into child part
c) 'PS' shows that a child process is active.
Code:
#include unistd.h
main()
{
int childId;
printf(Parent Process start \n);
if ( (childId = rfork(RFMEM | RFPROC) ) == 0 ) {
printf(In Child childId(%d) PId(%d)\n,
childId,getpid() );
sleep(4);
exit(0);
}
{
char buf[10] = Samit;
int nRet;
printf(Parent process continues with childId(%d)
%s,PID(%d)\n,
childId, buf,getpid());
sleep(5);
}
}
Output:
$ cc test.c
$ a.out
$ Parent Process start
Parent process continues with childId(10759) Samit,PID(10758)
ps
PID TT STAT TIME COMMAND
10697 p2 Ss 0:00.07 -sh (sh)
10758 p2 S 0:00.00 a.out
10759 p2 Z 0:00.00 (a.out)
10760 p2 R+ 0:00.00 ps
why it is created zombie and it does not execute the code ?
--Samit.
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()
Michael E. Mercer said: Hello, This was posted to freebsd-questions with no reply. I tried this and the child process created a core file. I also tried the other options and they seem to work. Just RFPROC and RFMEM DON'T! 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. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rfork()
John, With very little experience in assembly, could you or someone else give me a small example? Thanks in advance, Michael Mercer John S. Dyson wrote: Michael E. Mercer said: Hello, This was posted to freebsd-questions with no reply. I tried this and the child process created a core file. I also tried the other options and they seem to work. Just RFPROC and RFMEM DON'T! 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. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers 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, 20 Mar 1999, John S. Dyson wrote: Michael E. Mercer said: Hello, This was posted to freebsd-questions with no reply. I tried this and the child process created a core file. I also tried the other options and they seem to work. Just RFPROC and RFMEM DON'T! 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? thanks, -Alfred Index: rfork.2 === RCS file: /home/ncvs/src/lib/libc/sys/rfork.2,v retrieving revision 1.8 diff -u -r1.8 rfork.2 --- rfork.2 1999/01/26 02:38:09 1.8 +++ rfork.2 1999/03/21 04:49:10 @@ -54,7 +54,8 @@ will then inherit all the shared segments the parent process owns. Other segment types will be unaffected. Subsequent forks by the parent will then propagate the shared data and bss between children. The stack segment -is always split. May be set only with +is not split and must be allocated manually via an assembler subroutine. +May be set only with .Dv RFPROC . .It RFSIGSHARE If set, the kernel will force sharing the sigacts structure between the 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, John S. Dyson wrote: Michael E. Mercer said: Hello, This was posted to freebsd-questions with no reply. I tried this and the child process created a core file. I also tried the other options and they seem to work. Just RFPROC and RFMEM DON'T! 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? I suggest trying to find the example. I might have it sitting around here also. John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IPSEC support?
Is there any IPSEC support available for current? I've found support for 2.2.8, but not so far for current. KAME has support for 3.1-RELEASE. I don't know how far -current has diverged, but you might want to try www.kame.net. KAME is IP6 and IPSEC, but you can compile it with only IPSEC. You should note that KAME and the IPDIVERT option are mutually exclusive, unless they've fixed it in the last week (snaps come out Sunday/Monday and I haven't had the chance to test the last snap). If all else fails, you can hack up something using IPDIVERT that does ESP transport in userspace (not full IPSEC) in a weekend. At least that's how long it took me. The code is not ready to be released, and I'm not sure I want to go through the hassle of trying to export-control it at any rate (US citizen vs government stupidity). (ref the not full IPSEC, RFC2401 just came out a few months ago, is three times the size of the previous IPSEC RFC (1825), and mandates a lot of things that I'm not ready to start coding). 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, Alfred Perlstein wrote: On Sat, 20 Mar 1999, John S. Dyson wrote: Michael E. Mercer said: Hello, This was posted to freebsd-questions with no reply. I tried this and the child process created a core file. I also tried the other options and they seem to work. Just RFPROC and RFMEM DON'T! 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). thanks, -Alfred Index: rfork.2 === RCS file: /home/ncvs/src/lib/libc/sys/rfork.2,v retrieving revision 1.8 diff -u -r1.8 rfork.2 --- rfork.2 1999/01/26 02:38:09 1.8 +++ rfork.2 1999/03/21 04:49:10 @@ -54,7 +54,8 @@ will then inherit all the shared segments the parent process owns. Other segment types will be unaffected. Subsequent forks by the parent will then propagate the shared data and bss between children. The stack segment -is always split. May be set only with +is not split and must be allocated manually via an assembler subroutine. +May be set only with .Dv RFPROC . .It RFSIGSHARE If set, the kernel will force sharing the sigacts structure between the 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()
: 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. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
