Critical (or equivalent) section in Userland?

[Karl Pielorz]

Hi,

I'm writing a program under FreeBSD 3.X that has been forced into having to
make a number of rename() calls that must be completed atomically (i.e. all
together) without the process being interrupted, or any other process being
allowed to run...

The software is running as user 'root' - does anyone have any pointers on how
I can do this? (or how close I'll be able to get to doing this) - Theres only
going to be around 6 or 7 calls to rename() but I must ensure they _all_
happen before any other process is allowed to run again...

I realise that this doesn't exactly sound like good software engineering, but
it's the only way I can solve a problem I'm having with Sendmail... :(

Thanks for any info...

Regards,

Karl Pielorz


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[David Malone]

On Thu, Aug 17, 2000 at 09:28:02AM +0100, Karl Pielorz wrote:

> I'm writing a program under FreeBSD 3.X that has been forced into having to
> make a number of rename() calls that must be completed atomically (i.e. all
> together) without the process being interrupted, or any other process being
> allowed to run...

This isn't possible without serious hackery - you don't want to do
it.

If all the files exist below one directory you could swap the
directories with two renames, but that won't be atomic either. I
think your best bet would be rethink what you want to do.

David.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Anyone try the new dual-head G-400 drivers?

[thomas r stromberg]

   We're looking at buying some workstations for our network admins
   here, and dual head is a plus. We were looking at buying them from
   hardware.bsdi.com, and then today on Slashdot I saw:

   -
   Matrox has released a beta driver for their G200/G400/G450 which
   includes support for DualHead and QuadHead (up to 4 monitors), Flat
   Panel and TV out. This driver is a beta. You can get it here and I
   mirrored it here. You'll need XFree 4.0.1 in order to use this
   driver. Please follow the readme file carefully! (the readme file
   from Matrox's FTP needs to be converted dos2unix). Note: you cannot
   use the 3D hardware acceleration on the 2nd monitor (yet).
   -

   And of course, I was instantly happy when I saw this..

   Has anyone tried these drivers yet in FreeBSD? They look to be the
   OS-independant XFree86 4.0.1 modules (nothing funky like the NVIDIA
   ones). They come with some source code, but it appears to be
   wrappers around a missing HAL (?) library, though I could be wrong. 

   Please forward any successes/failures to the list.

-- 
thomas r. stromberg:   [EMAIL PROTECTED]
senior systems administrator   :  http://www.afterthought.org/
research triangle commerce, inc.   :1.919.657.1317  

 PGP signature

Re: Critical (or equivalent) section in Userland?

[Thomas Valentino Crimi]

Excerpts from FreeBSD-Hackers: 17-Aug-100 Critical (or equivalent) se..
by Karl [EMAIL PROTECTED] 
> The software is running as user 'root' - does anyone have any pointers on how
> I can do this? (or how close I'll be able to get to doing this) - Theres only
> going to be around 6 or 7 calls to rename() but I must ensure they _all_
> happen before any other process is allowed to run again...

  Take a look at rtprio(2), giving yourself a realtime priority will
guarantee you the CPU until you explicitly release it (or another higher
priority realtime process comes along).  I'm not sure if the same
deadlock potential that exists with giving a process an idle priority
exists due to locking in the kernel, although I see no mention of it in
the man pages.  It's definitely something I'd be wary of, though.

 Regards,
   Tom 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[Karl Pielorz]

Thomas Valentino Crimi wrote:

>   Take a look at rtprio(2), giving yourself a realtime priority will
> guarantee you the CPU until you explicitly release it (or another higher
> priority realtime process comes along).  I'm not sure if the same
> deadlock potential that exists with giving a process an idle priority
> exists due to locking in the kernel, although I see no mention of it in
> the man pages.  It's definitely something I'd be wary of, though.

Thanks, I'll look at that... Presumably, even though my process is making
syscalls, when they're completed - the scheduler _should_ look to run me
first, due to the very high priority?

If this doesn't work - I think I'm going to have to look to fixing the problem
(and removing the need to 'put the world on hold' while the program tinkers
with a few files)...

-Karl


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[David Malone]

On Thu, Aug 17, 2000 at 11:52:39AM -0400, Thomas Valentino Crimi wrote:

>   Take a look at rtprio(2), giving yourself a realtime priority will
> guarantee you the CPU until you explicitly release it (or another higher
> priority realtime process comes along).

I'd assume it is possible that one of the renames might block,
resulting in some other process being scheduled. This would
certainly be possible over NFS.

David.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[John Polstra]

In article <[EMAIL PROTECTED]>,
Thomas Valentino Crimi  <[EMAIL PROTECTED]> wrote:
> > going to be around 6 or 7 calls to rename() but I must ensure they _all_
> > happen before any other process is allowed to run again...
> 
>   Take a look at rtprio(2), giving yourself a realtime priority will
> guarantee you the CPU until you explicitly release it (or another higher
> priority realtime process comes along).

It's generally a bad idea to use priorities to try to guarantee
exclusive access.  Think SMP.  If there are enough CPUs in the system,
all runnable processes will be running no matter what their priorities
are.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: freebsd and non-preemtive threads

[Doug White]

On Mon, 14 Aug 2000, Jonas Bulow wrote:

> I'm trying to build a preforked and threaded server. When it comes to
> the threading part it seems that non-preemtive threads have a lot of
> benefits if the server is a statefull-server. 
> 
> What I'm trying to say is that the server is not going to do a lot of
> computation for each request. The server will simply update it's state
> and respond about it's success. 

This reminds me of coroutines or userland select- or kqueue-based
"threading."  Coroutines is a bit more complex but a library is available.  
Select-based "threads" aren't too difficult to set up in C, you could use
http://www.nightmare.com/medusa, a Python implementation, as a starting
point.  Also most NNTP servers have been using techniques like this for
years.

The key to these types of systems is that they don't spend much time per
request.

Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED] |  www.FreeBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[Warner Losh]

In message <[EMAIL PROTECTED]> Karl Pielorz writes:
: I'm writing a program under FreeBSD 3.X that has been forced into having to
: make a number of rename() calls that must be completed atomically (i.e. all
: together) without the process being interrupted, or any other process being
: allowed to run...

If advisory locks won't work (and they almost always will for things
like this), then you could walk the process tree.  For all processes
that aren't suspended or yourself, send a SIGSTOP, keep a list.  Keep
going through the tree while you keep finding processes.  SIGSTOP
can't be caught or blocked, so you know you've stopped them).  Do your
operation, then send SIGCONT to all the processes that you sent a
SIGSTOP to.  Of course, this will likely be much harder than doing
advisory locking, but might be a way that you might be able to exactly
what you want.

Well, you may need an exception list of processes if your files aren't
on a local disk, but if they aren't on a local disk, this whole
excersize is pointless, right?

Warner

P.S.  Can you tell I'm partial to advisory locks?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[Warner Losh]

In message <[EMAIL PROTECTED]> Karl Pielorz writes:
: Thomas Valentino Crimi wrote:
: 
: >   Take a look at rtprio(2), giving yourself a realtime priority will
: > guarantee you the CPU until you explicitly release it (or another higher
: > priority realtime process comes along).  I'm not sure if the same
: > deadlock potential that exists with giving a process an idle priority
: > exists due to locking in the kernel, although I see no mention of it in
: > the man pages.  It's definitely something I'd be wary of, though.
: 
: Thanks, I'll look at that... Presumably, even though my process is making
: syscalls, when they're completed - the scheduler _should_ look to run me
: first, due to the very high priority?

Yes, but in the interrum others can schedule time.

: If this doesn't work - I think I'm going to have to look to fixing the problem
: (and removing the need to 'put the world on hold' while the program tinkers
: with a few files)...

You are better off doing an atomic operation.  trust me.
Alternatively, you should use advisory locks for anybody that is
cooperating with you.  You didn't indicate that this had to run in a
hostile environment.  Much easier to do, much more robust than messing
with rtprio and likely what you really want anyway.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: fam and fmon?

[Doug White]

On Tue, 15 Aug 2000, Brandon Fosdick wrote:

> Does anyone have fam working with fmon yet? The sgi page has a few
> mentions of it but they're a few months old.

man kqueue

Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED] |  www.FreeBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Mosix in FreeBSD.

[Jesús Arnáiz]

Hi everyone!

I have read some information about MOSIX which is some patch for the linux
kernel created to build super-computers from a net of PCs.

I want to know if is there some similar project (mosix or even clustering)
but for FreeBSD, if someone know some about it please let me know.

Thanks in advance.

Jesús Arnáiz.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: freebsd and non-preemtive threads

[John Polstra]

In article <[EMAIL PROTECTED]>,
Doug White  <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Aug 2000, Jonas Bulow wrote:
> 
> > I'm trying to build a preforked and threaded server. When it comes to
> > the threading part it seems that non-preemtive threads have a lot of
> > benefits if the server is a statefull-server. 
> > 
> > What I'm trying to say is that the server is not going to do a lot of
> > computation for each request. The server will simply update it's state
> > and respond about it's success. 
> 
> This reminds me of coroutines or userland select- or kqueue-based
> "threading."  Coroutines is a bit more complex but a library is available.  
> Select-based "threads" aren't too difficult to set up in C, you could use
> http://www.nightmare.com/medusa, a Python implementation, as a starting
> point.

Or use the very nice "eventlib" package from the ISC.  It is
released as a part of BIND, and you can find it in FreeBSD's
"src/contrib/bind/lib/isc" directory (along with some other stuff).

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Anyone try the new dual-head G-400 drivers?

[Greg Lehey]

On Thursday, 17 August 2000 at 11:13:35 -0400, thomas r stromberg wrote:
>We're looking at buying some workstations for our network admins
>here, and dual head is a plus. We were looking at buying them from
>hardware.bsdi.com, and then today on Slashdot I saw:
>
>-
>Matrox has released a beta driver for their G200/G400/G450 which
>includes support for DualHead and QuadHead (up to 4 monitors), Flat
>Panel and TV out. This driver is a beta. You can get it here and I
>mirrored it here. You'll need XFree 4.0.1 in order to use this
>driver. Please follow the readme file carefully! (the readme file
>from Matrox's FTP needs to be converted dos2unix). Note: you cannot
>use the 3D hardware acceleration on the 2nd monitor (yet).
>-
>
>And of course, I was instantly happy when I saw this..

I'd be even happier if I knew where "here" was.

>Has anyone tried these drivers yet in FreeBSD? 

No, but I'd like to.  I have finally installed XFree 4.0 on my
machine, and now have the board working in single-head mode, but it
would be nice to get the second one working too.

>They look to be the OS-independant XFree86 4.0.1 modules (nothing
>funky like the NVIDIA ones). They come with some source code, but
>it appears to be wrappers around a missing HAL (?) library,
>though I could be wrong.

I don't think you are.  This was very much the intention.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[Warner Losh]

In message <[EMAIL PROTECTED]> Karl Pielorz writes:
: I don't think advisory locks will work - the other process is sendmail... I
: have to keep it from opening any of it's config files, whilst I 'rename' out
: of place the old ones (keeping any fd's to them intact) and rename in the new
: ones...

Don't fight sendmail :-)

: Killing / stopping the root sendmail doesn't work (as children making multiple
: deliveries still apparently open these  files at will) - and killing all of
: them isn't really an option either (as too many emails will be dropped, this
: means junking say, a 90% of the way through 3mb email delivery - only to have
: to resend/process it again from scratch).

Kill sendmail's root process.  That's the best you can do.  It won't
impact anything, it will prevent the reading of the queue files (and
the config files) and the children will just run with the old copies.
then you wait for all the children to die (with a reasonable
timeout).  Then you do your change, then restart sendmail.  That's the 
best you can hope for.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: freebsd and non-preemtive threads

[Kevin Mills]

>
> This reminds me of coroutines or userland select- or kqueue-based
> "threading."  Coroutines is a bit more complex but a library is
> available.

I've seen the term 'kqueue-based threading' on this list a few times now.
Could you explain what you mean by that?

Thanks!



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Anyone try the new dual-head G-400 drivers?

[Jeroen C. van Gelderen]

thomas r stromberg wrote:
> 
>We're looking at buying some workstations for our network admins
>here, and dual head is a plus. We were looking at buying them from
>hardware.bsdi.com, and then today on Slashdot I saw:
> 
>-
>Matrox has released a beta driver for their G200/G400/G450 which
>includes support for DualHead and QuadHead (up to 4 monitors), Flat
>Panel and TV out. This driver is a beta. You can get it here and I
>mirrored it here. You'll need XFree 4.0.1 in order to use this
>driver. Please follow the readme file carefully! (the readme file
>from Matrox's FTP needs to be converted dos2unix). Note: you cannot
>use the 3D hardware acceleration on the 2nd monitor (yet).
>-
> 
>And of course, I was instantly happy when I saw this..
> 
>Has anyone tried these drivers yet in FreeBSD? They look to be the
>OS-independant XFree86 4.0.1 modules (nothing funky like the NVIDIA
>ones). They come with some source code, but it appears to be
>wrappers around a missing HAL (?) library, though I could be wrong.
> 
>Please forward any successes/failures to the list.

I have a G400Max (32MB) running dual head on 1600x1200. I've lost
my display once after exiting X but a remote login and reboot did
work. No crashes or lockups (knock on wood). 


[...]
Section "Device"
Identifier  "Matrox Millennium G400 32MB 1"
Driver  "mga"
BusID   "PCI:1:0:0"
Screen  0
EndSection

Section "Device"
Identifier  "Matrox Millennium G400 32MB 2"
Driver  "mga"
BusID   "PCI:1:0:0"
Screen  1
EndSection

Section "Screen"
Identifier  "Screen 1"
Device  "Matrox Millennium G400 32MB 1"
Monitor "Vision Master Pro 510"
DefaultDepth 24

Subsection "Display"
Depth   24
Modes   "1600x1200"
ViewPort0 0
EndSubsection
EndSection

Section "ServerLayout"
Identifier  "Simple Layout"
Screen "Screen 1" RightOf "Screen 2"
Screen "Screen 2"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
[...]


[...]
FreeBSD 4.1-STABLE #0: Fri Aug 11 18:58:57 AST 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/GROLSCH
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (451.02-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x652  Stepping = 2
 
Features=0x183fbff
real memory  = 335532032 (327668K bytes)
avail memory = 322437120 (314880K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
IOAPIC #0 intpin 16 -> irq 11
IOAPIC #0 intpin 19 -> irq 10
FreeBSD/SMP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  1, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  0, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc03a9000.
Preloaded elf module "procfs.ko" at 0xc03a909c.
Preloaded elf module "vinum.ko" at 0xc03a913c.
Preloaded elf module "if_fxp.ko" at 0xc03a91dc.
Pentium Pro MTRR support enabled
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  on motherboard
pci0:  on pcib0
pcib1:  at device 1.0 on
pci0
pci1:  on pcib1
pci1:  at 0.0 irq 11
isab0:  at device 4.0 on pci0
isa0:  on isab0
atapci0:  port 0xd800-0xd80f at device 4.1
on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0:  at 4.2 irq 10
Timecounter "PIIX"  frequency 3579545 Hz
chip1:  port 0xe800-0xe80f at
device 
4.3 on pci0
ahc0:  port 0xd000-0xd0ff mem
0xe000
-0xefff irq 10 at device 6.0 on pci0
ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
fxp0:  port 0xb800-0xb83f mem
0xdf00-0xdf0f
,0xdf80-0xdf800fff irq 10 at device 9.0 on pci0
fxp0: Ethernet address 00:90:27:88:f0:64
pcm0:  port 0xb400-0xb43f irq 11 at device 12.0 on pci0
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on
isa0
fdc0: FIFO enabled, 8 bytes threshold
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  irq 1 on atkbdc0
psm0:  irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on
isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
[...]

-- 
Jeroen C. van Gelderen  o  _ _ _
[EMAIL PROTECTED]  _o /\_   _ \\o  (_)\__/o  (_)
  _< \_   _>(_) (_)/<_\_| \   _|/' \/
 (_)>(_) (_)(_)   (_)(_)'  _\o_


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[Archie Cobbs]

David Malone writes:
> > I'm writing a program under FreeBSD 3.X that has been forced into having to
> > make a number of rename() calls that must be completed atomically (i.e. all
> > together) without the process being interrupted, or any other process being
> > allowed to run...
> 
> If all the files exist below one directory you could swap the
> directories with two renames, but that won't be atomic either. I
> think your best bet would be rethink what you want to do.

It could still work as long as at startup you check for any
half-completed operation and finish it, e.g.:

  mkdir mydir.new
  copy/modify files in mydir.new
  mv mydir mydir.old
  mv mydir.new mydir

Then on startup (e.g., after a crash), if "mydir" doesn't exist,
simply "mv mydir.new mydir; rm -rf mydir.old" before proceeding.

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: several NFS mounts within a filesystem

[Douglas K. Rand]

** Peter Pentchev <[EMAIL PROTECTED]> on Wed, 16 Aug 2000 19:47:52 +0300
** in [several NFS mounts within a filesystem] writes:

Peter> OK, so it might very well be that I haven't read everything; in that
Peter> case, sorry for taking your time. However..

Peter> Am I right in thinking that the kernel won't let me export more
Peter> than one subdir of the same filesystem?  If so, how do I get
Peter> around this?

What you want to do is either include the -alldirs as "Kenneth
D. Merry" <[EMAIL PROTECTED]> suggests, or list the directories you want to
export on the same line. From my /etc/exports:

   /usr/ports /usr/src /usr/obj-network=x.x.x.0 -mask=255.255.255.0 -maproot=root

/usr/ports, /use/src, and /usr/obj are all on the /usr file system,
and this exports only those directories.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[Karl Pielorz]

Warner Losh wrote:

> If advisory locks won't work (and they almost always will for things
> like this), then you could walk the process tree.  For all processes
> that aren't suspended or yourself, send a SIGSTOP, keep a list.

I don't think advisory locks will work - the other process is sendmail... I
have to keep it from opening any of it's config files, whilst I 'rename' out
of place the old ones (keeping any fd's to them intact) and rename in the new
ones...

Killing / stopping the root sendmail doesn't work (as children making multiple
deliveries still apparently open these  files at will) - and killing all of
them isn't really an option either (as too many emails will be dropped, this
means junking say, a 90% of the way through 3mb email delivery - only to have
to resend/process it again from scratch).

> going through the tree while you keep finding processes.  SIGSTOP
> can't be caught or blocked, so you know you've stopped them).  Do your
> operation, then send SIGCONT to all the processes that you sent a
> SIGSTOP to.

I like the sound of this... The only race I could see would be if one of the
sendmail's had issued the open() to open the file, but on the other hand, it
will either get 'stopped' before this syscall (in which case it will open()
the 'new' file when it gets continued), or it will get stopped after the
open() in which case the FD it has will still be valid, as the old file still
exists and has only been renamed... It can't get stopped in the middle of the
open() call - can it? [Now I am being paranoid! - I'm sure it can't... Yet in
FreeBSD...]

>  Of course, this will likely be much harder than doing
> advisory locking, but might be a way that you might be able to exactly
> what you want.

Presumably for advisory locking, I'm right in thinking I'd have to tinker with
the sendmail source, so it also uses advisory locking etc?
 
> Well, you may need an exception list of processes if your files aren't
> on a local disk, but if they aren't on a local disk, this whole
> excersize is pointless, right?

All the files are local... They're re-built from a database, on an
all-to-often basis... (Hence the need to HUP sendmail, without killing all
it's kids etc.) 
 
> P.S.  Can you tell I'm partial to advisory locks?

Yes... :) - They would be a better way of doing it! - But I'd rather not mess
with Sendmail :)


Also, A big "Thanks" to all that replied... I've posted two questions to
-hackers recently, and netted two very good replies...

-Karl


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Bootable CD...

[Patrick Bihan-Faou]

Hi,


I am trying to build a bootable CD... Now this sounds like something trivial
enough to do when you know what you are doing. In my case I must admit that
I am somewhat confused.

Until now, I think that the trick was to make the CD look like a floppy and
boot it as such. I have created some bootable CDs in the past and they
seemed to work OK.

However it looks like things have changed recently in the way CD-Roms are
booted, and I am not able to create a working CD anymore.

What I would like to clarify is what needs to be in the "2.88 M" bootable
image ?

Here is what I have:

/boot
/boot0
/boot1
/boot2
/loader
/cdboot
/pxeboot
/loader.config
/loader.rc
/boot.config
/kernel.config
/kernel.gz
/modules
...
/usr/sbin
ibcs2
linux
svr4


Now whenever I boot this image, the loader dies displaying a all whack hex
values and saying "BTX Halted".


I am a bit confused as to what to do next, and I would really appreciate any
help.

BTW I am working on a fresh copy of FreeBSD 4.1-STABLE (checked-out August
15).


Patrick.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Critical (or equivalent) section in Userland?

[Brian Somers]

> In message <[EMAIL PROTECTED]> Karl Pielorz writes:
> : I'm writing a program under FreeBSD 3.X that has been forced into having to
> : make a number of rename() calls that must be completed atomically (i.e. all
> : together) without the process being interrupted, or any other process being
> : allowed to run...
> 
> If advisory locks won't work (and they almost always will for things
> like this), then you could walk the process tree.  For all processes
> that aren't suspended or yourself, send a SIGSTOP, keep a list.  Keep
> going through the tree while you keep finding processes.  SIGSTOP
> can't be caught or blocked, so you know you've stopped them).  Do your
> operation, then send SIGCONT to all the processes that you sent a
> SIGSTOP to.  Of course, this will likely be much harder than doing
> advisory locking, but might be a way that you might be able to exactly
> what you want.

Wow, forgive me for saying this, but it must take a warped mind to 
think of that !!! :-)

Now if the original poster could arrange that all the files are 
either in the same directory or symlinked to the same directory, a 
quick directory rename (or symlink move) may do the job.  If that's 
not atomic enough, you could always replace that chunk of filesystem 
with a mount().

> Warner
> 
> P.S.  Can you tell I'm partial to advisory locks?

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: what to do about /tmp

[Allen Pulsifer]

Matt,

I noticed /tmp and /var/tmp are used slightly differently, for example, the
contents of /tmp are not expected to survive a reboot, while /var/tmp is
used for files you might need after a crash, like vi recovery files.

It makes sense to me to mount /tmp using MFS.  The symantics of /tmp and VM
are very close: its a bunch of data that you would like to keep in RAM if
possible, but can be pushed out to disk if needed.  And you don't care about
metadata, file system consistency and whether it survives a crash.

One advantage of mounting /tmp with MFS is that you don't have use up another
disk partition.  Performance-wise, I would think data moves something
like this:

/tmp on MFS:
   application data --> kernel VM --> paged to disk

/tmp on FFS:
   application data --> kernel file buffer --> flushed to disk

Is that basically correct?  What makes MFS less efficient than FFS?
What would be the implications of creating a 512 MB swap partition
and mounting an MFS /tmp?

Thanks,

Allen



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: freebsd and non-preemtive threads

[Doug White]

On Thu, 17 Aug 2000, Kevin Mills wrote:

> >
> > This reminds me of coroutines or userland select- or kqueue-based
> > "threading."  Coroutines is a bit more complex but a library is
> > available.
> 
> I've seen the term 'kqueue-based threading' on this list a few times now.
> Could you explain what you mean by that?

I think I coined it. :)  It's the technique of using kqueue to multiplex
I/O.  You can create highly efficient multi-connection servers by using
kqueue (or select/poll) to dispatch work.  It works very nicely for
protocols like SMTP that have a send/response style, where you receive a
command, process it, and send back the response.  When you send or
receive, you do the read or write nonblocking and let kqueue/select/poll
tell you when it's done.

The URL I quoted in my last message is a Python implementation of
select-based threading.  We've done a somewhat trivial port of it to
kqueue and are working on a better integration module.

Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED] |  www.FreeBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: Anyone try the new dual-head G-400 drivers?

[Alexander N. Kabaev]

This driver will not run on FreeBSD most likely. It seems like the driver needs
Linux framebuffer device to run. 

On 17-Aug-00 thomas r stromberg wrote:
>We're looking at buying some workstations for our network admins
>here, and dual head is a plus. We were looking at buying them from
>hardware.bsdi.com, and then today on Slashdot I saw:
> 
>-
>Matrox has released a beta driver for their G200/G400/G450 which
>includes support for DualHead and QuadHead (up to 4 monitors), Flat
>Panel and TV out. This driver is a beta. You can get it here and I
>mirrored it here. You'll need XFree 4.0.1 in order to use this
>driver. Please follow the readme file carefully! (the readme file
>from Matrox's FTP needs to be converted dos2unix). Note: you cannot
>use the 3D hardware acceleration on the 2nd monitor (yet).
>-
> 
>And of course, I was instantly happy when I saw this..
> 
>Has anyone tried these drivers yet in FreeBSD? They look to be the
>OS-independant XFree86 4.0.1 modules (nothing funky like the NVIDIA
>ones). They come with some source code, but it appears to be
>wrappers around a missing HAL (?) library, though I could be wrong. 
> 
>Please forward any successes/failures to the list.
> 
> -- 
> thomas r. stromberg:   [EMAIL PROTECTED]
> senior systems administrator   :  http://www.afterthought.org/
> research triangle commerce, inc.   :1.919.657.1317

--
E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]>
Date: 17-Aug-00
Time: 22:43:41
--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

'group' in ioctl()

[FUJITA Kazutoshi]

Hi, hackers.

I have been given the task of writing a PCI device driver for
a special card on 4.0-RELEASE.
But I'm novice in device driver programming.

In writing ioctl routine, I have to decide ioctl command code.
So I saw some other device driver source code and system header
files, I found some macros in .

#define _IOC(inout,group,num,len) \
((unsigned long)(inout | ((len & IOCPARM_MASK) << 16) | ((group) << 8) | 
(num)))
#define _IO(g,n)_IOC(IOC_VOID,  (g), (n), 0)
#define _IOR(g,n,t) _IOC(IOC_OUT,   (g), (n), sizeof(t))
#define _IOW(g,n,t) _IOC(IOC_IN,(g), (n), sizeof(t))
/* this should be _IORW, but stdio got there first */
#define _IOWR(g,n,t)_IOC(IOC_INOUT, (g), (n), sizeof(t))

What 'group' should I use ?


Regards,


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message