Date: Sat, 21 Mar 1998 17:25:42 -0800 From: "szabo" <tszabo@earthlink.net> To: <hackers@FreeBSD.ORG> Subject: Re: freebsd-hackers-digest V4 #75 Message-ID: <199803220130.RAA06352@norway.it.earthlink.net>
next in thread | raw e-mail | index | archive | help
Please cancel this newsletter. Thank you. ---------------TOM------------------- ---------- > From: freebsd-hackers-digest <owner-freebsd-hackers-digest@FreeBSD.ORG> > To: freebsd-hackers-digest@FreeBSD.ORG > Subject: freebsd-hackers-digest V4 #75 > Date: Saturday, March 21, 1998 1:48 PM > > > freebsd-hackers-digest Saturday, March 21 1998 Volume 04 : Number 075 > > > > In this issue: > Re: mremap? > Re: SCO (was Re: hi terry) > Re: newmsdosfs anyone ? > Re: SCO (was Re: hi terry) > Re: SCO (was Re: hi terry) > Re: SCO (was Re: hi terry) > Re: newmsdosfs anyone ? > apologies for mail loop > Re: newmsdosfs anyone ? > Re: newmsdosfs anyone ? > patch for Vibra16X -- test please! > New vx driver (Re: vx device (3c905-100mb) ) > XTI (shudder) > Re: New vx driver (Re: vx device (3c905-100mb) ) > Re: newmsdosfs anyone ? > Re: SCO (was Re: hi terry) > Re: mremap? > Re: How do you increase available SYSV shared memory? > Re: New vx driver (Re: vx device (3c905-100mb) ) > Re: How do you increase available SYSV shared memory? > Re: How do you increase available SYSV shared memory? > Re: How do you increase available SYSV shared memory? > Re: mremap? > Re: mremap? > Re: Discussion about script to update /etc, etc. > Re: mremap? > (Fwd) Re: Natd Support for Microsoft PPTP / VPN using protocol > Re: mremap? > Need Intel 82557/82558 Ethernet docs to hack if_fxp. > FW: Digi Exp > Re: 3.0-971225SNAP, Japanese/Korean locales, and libxpg4 > fxp strange problem > Re: mremap? > Re: fxp strange problem > inetd in realloc():warning:junk pointer, towo low to make sense. > Re: inetd in realloc():warning:junk pointer, towo low to make sense. > Re: netscape4 weirdness: what is happening here?? > ANNOUNCE: PicoBSD 0.31 > Re: How do you increase available SYSV shared memory? > > ---------------------------------------------------------------------- > > Date: Fri, 20 Mar 1998 08:38:29 -0800 > From: Mike Smith <mike@smith.net.au> > Subject: Re: mremap? > > > ok, i'm not promising anything here, but if i implemented mremap(), would > > there be any interest in allowing it into -current? > > > > mremap just allows for moving and resizing mmap'd segments. > > You're more than welcome to give it a try. I had a look at the way > Linux does it, and frankly the layering violations were pretty shocking > (although there appears to be a great deal less sophistication in their > VM system). > > I couldn't see how to provide similar functionality with FreeBSD, but > if you're willing to get a little close to the way that memory mapping > works (check with David Greenman if you need advice here) you should be > able to pull it off. > > > btw, i'm planning on implementing it like the linux mremap(), although there > > is some talk in the linux man page for it about a BSD version that was never > > done... if anyone would rather i try to do that i can look into it if > > someone can get me a man page to the BSD proposed version. > > If BSD/OS or NetBSD has mremap(), we would probably want to look like > theirs and support the Linux model via ABI emulation. Otherwise, I > can't see any reason not to simply be slavishly compatible. 8) > > - -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 08:42:26 -0800 > From: "Jordan K. Hubbard" <jkh@time.cdrom.com> > Subject: Re: SCO (was Re: hi terry) > > > Ron Minnich has been trying to shove his more-than-functional clustering > > implementation into our laps for the last two or three years now. I > > can hardly blame the guy for feeling distinctly ignored. > > Funny you should mention him since he just got in touch with me about > this and I apologised for what most of -core feels is one of our more > glaring failures to catch the ball. I think at this point that we > should simply coerce Ron somehow (anybody know of any exploitable > vices the guy has? :-) into joining -committers so that we're no > longer a bottleneck for him. > > Jordan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 11:44:09 -0500 (EST) > From: Snob Art Genre <benedict@echonyc.com> > Subject: Re: newmsdosfs anyone ? > > How about mkdosfs(1)? > > > > Ben > > "You have your mind on computers, it seems." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 18:41:43 +0200 > From: Ruslan Shevchenko <Ruslan@Shevchenko.Kiev.UA> > Subject: Re: SCO (was Re: hi terry) > > Mike Smith wrote: > > > ? ? But the industry is changing quite rapidly. I believe we need to > > ? ? step back and see where it is going and make some strategic > > ? ? decisions about where we want to see FreeBSD go. We have > > ? ? stability and security pretty well taken care of. I'm seeing > > ? ? some positive comments about smp in 3.0. But we might want to > > ? ? see about clustering and some fault-tolerant extensions. If we > > ? > > ? Heh. I think we first mentioned clustering as something on FreeBSD's > > ? wishlist as early as 1995 or so. The problem here is not in finding > > ? enough people to say "yeah, clustering is cool!", the problem here is > > ? in finding people to say "clustering is cool, please check out my > > ? FreeBSD implementation!" :-( > > > > No, the problem is finding people to say "wow, I have checked out this > > FreeBSD clustering implementation and I think it ?verb?s". > > > > Ron Minnich has been trying to shove his more-than-functional clustering > > implementation into our laps for the last two or three years now. I > > can hardly blame the guy for feeling distinctly ignored. > > > > Hmm. I know nothing about this and I'm ready to try > this. > Can I see http://www.freebsd.org/cluster in near future ? > > > If we have someone that actually feels "proactive" about clustering, > > then I suggest they approach Ron solicitously and get something > > happening. 8) > > > > -- > > \\ Sometimes you're ahead, \\ Mike Smith > > \\ sometimes you're behind. \\ mike@smith.net.au > > \\ The race is long, and in the \\ msmith@freebsd.org > > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > - -- > > @= > //RSSH mailto:Ruslan@Shevchenko.Kiev.UA > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 12:01:57 -0500 (EST) > From: Open Systems Networking <opsys@mail.webspan.net> > Subject: Re: SCO (was Re: hi terry) > > On Fri, 20 Mar 1998, Jordan K. Hubbard wrote: > > > Funny you should mention him since he just got in touch with me about > > this and I apologised for what most of -core feels is one of our more > > glaring failures to catch the ball. I think at this point that we > > should simply coerce Ron somehow (anybody know of any exploitable > > vices the guy has? :-) into joining -committers so that we're no > > longer a bottleneck for him. > > Ill second that! Maybe we'll see clustering maybe we wont :) > But At least we can offer those doing the work the chance to take their, > in this case, cluster work and integrate it with little overhead, when the > code meets the specs. I think of projects that have been done to add > funtionality and more than anything just selling points and buzzwords, for > isntance gene starks DSM for FBSD. It would have had some useage somewhere > im sure, but for most of us, not really. But It was work done and > completed, just never integrated into the src. That really isnt a good > point since even if it had been intergrated i doubt gene would be hacking > on it to keep it cruft free and working. So maybe thats a bad example :) > But ron will probably keep his cluster code working and compilable, so I > think jordans idea is a good one, even if this was a long winded way to > say it. Oh and wine and woman usually are the 2 standard exploits for most > of us :) > > ./wine -red -exploit ron > ./women -seduce -3on1 ron > > Source is freely availble! > > Chris > > - -- > "I am closed minded. It keeps the rain out." > > ===================================| Open Systems Networking And Consulting. > FreeBSD 2.2.5 is available now! | Phone: 316-326-6800 > - -----------------------------------| 1402 N. Washington, Wellington, KS-67152 > FreeBSD: The power to serve! | E-Mail: opsys@open-systems.net > http://www.freebsd.org | Consulting-Network Engineering-Security > ===================================| http://open-systems.net > > - -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: 2.6.2 > > mQENAzPemUsAAAEH/06iF0BU8pMtdLJrxp/lLk3vg9QJCHajsd25gYtR8X1Px1Te > gWU0C4EwMh4seDIgK9bzFmjjlZOEgS9zEgia28xDgeluQjuuMyUFJ58MzRlC2ONC > foYIZsFyIqdjEOCBdfhH5bmgB5/+L5bjDK6lNdqD8OAhtC4Xnc1UxAKq3oUgVD/Z > d5UJXU2xm+f08WwGZIUcbGcaonRC/6Z/5o8YpLVBpcFeLtKW5WwGhEMxl9WDZ3Kb > NZH6bx15WiB2Q/gZQib3ZXhe1xEgRP+p6BnvF364I/To9kMduHpJKU97PH3dU7Mv > CXk2NG3rtOgLTEwLyvtBPqLnbx35E0JnZc0k5YkABRO0JU9wZW4gU3lzdGVtcyA8 > b3BzeXNAb3Blbi1zeXN0ZW1zLm5ldD4= > =BBjp > - -----END PGP PUBLIC KEY BLOCK----- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 18:03:36 +0100 > From: Philippe Regnauld <regnauld@deepo.prosa.dk> > Subject: Re: SCO (was Re: hi terry) > > Jordan K. Hubbard writes: > > > > Funny you should mention him since he just got in touch with me about > > this and I apologised for what most of -core feels is one of our more > > glaring failures to catch the ball. I think at this point that we > > should simply coerce Ron somehow (anybody know of any exploitable > > vices the guy has? :-) into joining -committers so that we're no > > longer a bottleneck for him. > > http://www.sarnoff.com:8000/docs/metacomputing.html > > Nudge, nudge. > > - -- > -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- > «Pluto placed his bad dog at the entrance of Hades to keep the dead > IN and the living OUT! The archetypical corporate firewall?» > - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 16:40:30 +0100 (MET) > From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> > Subject: Re: newmsdosfs anyone ? > > > How about mkdosfs(1)? > > so much for not having appropriate manpages... > > prova# which mkdosfs > /usr/sbin/mkdosfs > prova# man -k msdos | grep mkdosfs > prova# man -k FAT > mkdosfs(1) - create an MS-DOS (FAT) file system > > no need to say i did not think to run man -k FAT before asking... > > cheers > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 11:38:49 -0600 > From: dannyman <dannyman@SASQUATCH.dannyland.org> > Subject: apologies for mail loop > > hello, > > for about two hours this morning, i had a bad bad bad bad majordomo recipe > which was causing every piece of mail I received to be auto-responded to. i > would like to apologise for any crap spewed upon the lists because of this. i > feel pretty dumb. sorry everyone. > > - -dan > > - -- > //Dan -=- This message brought to you by djhoward@uiuc.edu -=- > \\/yori -=- Information - http://www.uiuc.edu/ph/www/djhoward/ -=- > aiokomete -=- Our Honored Symbol deserves an Honorable Retirement > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 19:59:49 +0200 (SAT) > From: Robert Nordier <rnordier@iafrica.com> > Subject: Re: newmsdosfs anyone ? > > Luigi Rizzo wrote: > > > Hi, > > > > i am in the need of creating a formatted MSDOS filesystem on >512MB > > disks from FreeBSD. > > > > One option i used was mtools but only for small disks, and i am not > > sure how it works with larger disks. In any case, i was wondering if > > there is some smaller code doing only the formatting part of the work... > > > > thanks > > luigi > > The latest mtools works pretty well for large disks. > > I have a revised mkdosfs (the current FreeBSD one only does floppies) > which I've been meaning to polish and submit, anyway. This handles > FAT12, FAT16, and FAT32. If you want to review/test it, I can send > it to you by the end of next week. > > - -- > Robert Nordier > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 18:10:37 +0100 (MET) > From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> > Subject: Re: newmsdosfs anyone ? > > > The latest mtools works pretty well for large disks. > > 3.8 or later ? > > > I have a revised mkdosfs (the current FreeBSD one only does floppies) > > which I've been meaning to polish and submit, anyway. This handles > > FAT12, FAT16, and FAT32. If you want to review/test it, I can send > > it to you by the end of next week. > > yes i'd be interested. > > I have patches (for mtools 3.0) to support HDs (but only up to 512MB) > and make them bootable in DOS or Windows95 (you need a DOS/Win > licence, and you need to grab the init files and boot sector and put > them into /usr/local/lib/mtools... > > Would you be interested to integrate that as well ? > > cheers > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 18:14:52 +0100 (MET) > From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> > Subject: patch for Vibra16X -- test please! > > [forgive me for the crosspost but I'm trying to get some feedback > quickly... since this might go into -stable and the deadline is > close...] > > By popular demand, enclosed is a small patch to hopefully add > PARTIAL Vibra16X support for playback (there is also some still > non-functional code for the ESS -- don't worry about that bu i > prefer not to handcraft the patchfile). This is mostly derived from > code contributed by Torsten Ackemann. > > The diff is against snd980215 which is essentially what is now in > - -current and -stable. The modified files are only sb_dsp.c and > sbcard.h > > Note that, assuming this code works at all: > > * it might affect plain SB16 support, so I'd like to have feedback from > someone with the SB16 (it should still work fine); > * it only works in playback; we haven't figured out yet how > to tell capture from playback interrupts. And I have not > been successful in getting documentation from Creative or Realtek > (the latter make a Vibra16X clone). > * you might have to add the PnP vend_id of your card near the > end of sb_dsp.c -- there is a comment marked with VIBRA16X in this patch > in the point where you should make the addition. > > As usual, feedback is not only welcome but absolutely necessay > since I don't have a Vibra16X or clone. I need to know both if it > works and if it not works. Do not forget to give details about > your card (e.g. brand, PnP vendor ID) > > cheers > luigi > > > diff -ubwr snd/sb_dsp.c /sys/i386/isa/snd/sb_dsp.c > - --- snd/sb_dsp.c Tue Jan 27 21:01:49 1998 > +++ /sys/i386/isa/snd/sb_dsp.c Fri Mar 20 19:32:52 1998 > @@ -275,9 +275,12 @@ > * SB < 4.0 is half duplex and has only 1 bit for int source, > * so we fake it. SB 4.x (SB16) has the int source in a separate > * register. > + * The Vibra16X has separate flags for 8 and 16 bit transfers, but > + * I have no idea how to tell capture from playback interrupts... > */ > +#define PLAIN_SB16(x) ( ( (x) & (BD_F_SB16|BD_F_SB16X) ) == BD_F_SB16) > again: > - - if (d->bd_flags & BD_F_SB16) { > + if (PLAIN_SB16(d->bd_flags)) { > c = sb_getmixer(io_base, IRQ_STAT); > /* this tells us if the source is 8-bit or 16-bit dma. We > * have to check the io channel to map it to read or write... > @@ -302,7 +305,7 @@ > if ( d->dbuf_out.dl ) > dsp_wrintr(d); > else { > - - if (d->bd_flags & BD_F_SB16) > + if (PLAIN_SB16(d->bd_flags)) > printf("WARNING: wrintr but write DMA inactive!\n"); > } > } > @@ -310,7 +313,7 @@ > if ( d->dbuf_in.dl ) > dsp_rdintr(d); > else { > - - if (d->bd_flags & BD_F_SB16) > + if (PLAIN_SB16(d->bd_flags)) > printf("WARNING: rdintr but read DMA inactive!\n"); > } > } > @@ -353,7 +356,7 @@ > else > d->flags &= ~SND_F_XLAT8 ; > > - - if (d->bd_flags & BD_F_SB16) { > + if (PLAIN_SB16(d->bd_flags)) { > u_char c, c1 ; > > /* the SB16 can do full duplex using one 16-bit channel > @@ -392,6 +395,29 @@ > d->dbuf_in.chan = d->dbuf_out.chan; > d->dbuf_out.chan = c ; > } > + } else if (d->bd_flags & BD_F_ESS) { > + u_char c ; > + if (d->play_fmt == 0) { > + /* initialize for record */ > + static u_char cmd[] = { > + 0x51,0xd0,0x71,0xf4,0x51,0x98,0x71,0xbc > + }; > + ess_write(d->io_base, 0xb8, 0x0e); > + c = ( ess_read(d->io_base, 0xa8) & 0xfc ) | 1 ; > + if (d->flags & SND_F_STEREO) > + c++ ; > + ess_write(d->io_base, 0xa8, c); > + ess_write(d->io_base, 0xb9, 2); /* 4bytes/transfer */ > + /* > + * set format in b6, b7 > + */ > + } else { > + /* initialize for play */ > + static u_char cmd[] = { > + 0x80,0x51,0xd0,0x00,0x71,0xf4, > + 0x80,0x51,0x98,0x00,0x71,0xbc > + }; > + } > } > reset_dbuf(& (d->dbuf_in), SND_CHAN_RD ); > reset_dbuf(& (d->dbuf_out), SND_CHAN_WR ); > @@ -406,7 +432,10 @@ > * is assigned. This means that if the application > * tries to use a bad format, the sound will not be nice. > */ > - - if ( b->chan > 4 ) { > + if ( b->chan > 4 > + || (rd && d->rec_fmt == AFMT_S16_LE) > + || (!rd && d->play_fmt == AFMT_S16_LE) > + ) { > c = DSP_F16_AUTO | DSP_F16_FIFO_ON | DSP_DMA16 ; > c1 = DSP_F16_SIGNED ; > l /= 2 ; > @@ -455,7 +484,10 @@ > case SND_CB_STOP : > { > int cmd = DSP_CMD_DMAPAUSE_8 ; /* default: halt 8 bit chan */ > - - if ( d->bd_flags & BD_F_SB16 && b->chan > 4 ) > + if ( b->chan > 4 > + || (rd && d->rec_fmt == AFMT_S16_LE) > + || (!rd && d->play_fmt == AFMT_S16_LE) > + ) > cmd = DSP_CMD_DMAPAUSE_16 ; > if (d->bd_flags & BD_F_HISPEED) { > sb_reset_dsp(d->io_base); > @@ -618,7 +650,7 @@ > printf("ESS1868 (rev %d)\n", rev); > else > printf("ESS688 (rev %d)\n", rev); > - - d->audio_fmt |= AFMT_S16_LE; /* in fact it is U16_LE */ > + /* d->audio_fmt |= AFMT_S16_LE; */ /* not yet... */ > break ; /* XXX */ > } else { > printf("Unknown card 0x%x 0x%x -- hope it is SBPRO\n", > @@ -661,6 +693,14 @@ > > /* > * Common code for the midi and pcm functions > + * > + * sb_cmd write a single byte to the CMD port. > + * sb_cmd2 write a CMD + 1 byte arg > + * sb_cmd3 write a CMD + 2 byte arg > + * sb_get_byte returns a single byte from the DSP data port > + * > + * ess_write is actually sb_cmd2 > + * ess_read access ext. regs via sb_cmd(0xc0, reg) followed by sb_get_byte > */ > > int > @@ -726,9 +766,9 @@ > u_long flags; > > flags = spltty(); > - - outb(io_base + 4, (u_char) (port & 0xff)); /* Select register */ > + outb(io_base + SB_MIX_ADDR, (u_char) (port & 0xff)); /* Select register */ > DELAY(10); > - - val = inb(io_base + 5); > + val = inb(io_base + SB_MIX_DATA); > DELAY(10); > splx(flags); > > @@ -748,6 +788,19 @@ > return 0xffff; > } > > +int > +ess_write(int io_base, u_char reg, int val) > +{ > + return sb_cmd2(io_base, reg, val); > +} > + > +int > +ess_read(int io_base, u_char reg) > +{ > + if (!sb_cmd(io_base, 0xc0) || !sb_cmd(io_base, reg) ) > + return 0xffff ; > + return sb_get_byte(io_base); > +} > > > /* > @@ -786,17 +839,21 @@ > */ > if (d->bd_flags & BD_F_ESS) { > int t; > - - RANGE (speed, 4000, 48000); > + RANGE (speed, 5000, 49000); > if (speed > 22000) { > t = (795500 + speed / 2) / speed; > speed = (795500 + t / 2) / t ; > - - t = ( 256 - (795500 + speed / 2) / speed ) | 0x80 ; > + t = (256 - t ) | 0x80 ; > } else { > t = (397700 + speed / 2) / speed; > speed = (397700 + t / 2) / t ; > - - t = 128 - (397700 + speed / 2) / speed ; > + t = 128 - t ; > } > - - sb_cmd2(d->io_base, 0xa1, t); /* set time constant */ > + ess_write(d->io_base, 0xa1, t); /* set time constant */ > + d->play_speed = d->rec_speed = speed ; > + speed = (speed * 9 ) / 20 ; > + t = 256-7160000/(speed*82); > + ess_write(d->io_base,0xa2,t); > return speed ; > } > > @@ -1154,6 +1211,7 @@ > * A driver for some SB16pnp and compatibles... > * > * Avance Asound 100 -- 0x01009305 > + * Avance Logic ALS100+ -- 0x10019305 > * xxx -- 0x2b008c0e > * > */ > @@ -1187,6 +1245,8 @@ > s = "SB16 PnP"; > else if (vend_id == 0x01009305) > s = "Avance Asound 100" ; > + else if (vend_id == 0x10009305) > + s = "Avance Logic 100+" ; > if (s) { > struct pnp_cinfo d; > read_pnp_parms(&d, 0); > @@ -1224,6 +1284,12 @@ > pcm_info[dev->id_unit] = tmp_d; > snddev_last_probed->probe(dev); /* not really necessary but doesn't harm */ > > + if (vend_id == 0x10009305) { > + /* > + * VIBRA16X please add here the vend_id for other vibra16X cards... > + */ > + pcm_info[dev->id_unit].bd_flags |= BD_F_SB16X ; > + } > pcmattach(dev); > } > #endif /* NPNP */ > Only in /sys/i386/isa/snd: sb_dsp.c.v16 > diff -ubwr snd/sbcard.h /sys/i386/isa/snd/sbcard.h > - --- snd/sbcard.h Fri Jan 16 19:03:44 1998 > +++ /sys/i386/isa/snd/sbcard.h Thu Mar 12 09:40:16 1998 > @@ -19,9 +19,9 @@ > #define DSP_DATA_AVAIL (io_base + 0xE) > #define DSP_DATA_AVL16 (io_base + 0xF) > > +#define SB_MIX_ADDR 0x4 > +#define SB_MIX_DATA 0x5 > #if 0 > - -#define MIXER_ADDR (io_base + 0x4) > - -#define MIXER_DATA (io_base + 0x5) > #define OPL3_LEFT (io_base + 0x0) > #define OPL3_RIGHT (io_base + 0x2) > #define OPL3_BOTH (io_base + 0x8) > @@ -138,7 +138,7 @@ > #define BD_F_MIX_CT1745 0x0030 /* CT1745 */ > > #define BD_F_SB16 0x0100 /* this is a SB16 */ > - -#define BD_F_NOREC 0x0200 /* recording not supported on this board */ > +#define BD_F_SB16X 0x0200 /* this is a vibra16X or clone */ > #define BD_F_MIDIBUSY 0x0400 /* midi busy */ > #define BD_F_ESS 0x0800 /* this is an ESS chip */ > > diff -ubwr snd/sound.c /sys/i386/isa/snd/sound.c > - --- snd/sound.c Fri Feb 13 15:33:08 1998 > +++ /sys/i386/isa/snd/sound.c Sat Mar 14 23:11:35 1998 > @@ -717,7 +717,7 @@ > snd_chan_param *p = (snd_chan_param *)arg; > d->play_speed = p->play_rate; > d->rec_speed = p->play_rate; /* XXX one speed allowed */ > - - if (p->play_format & SND_F_STEREO) > + if (p->play_format & AFMT_STEREO) > d->flags |= SND_F_STEREO ; > else > d->flags &= ~SND_F_STEREO ; > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 13:57:38 -0500 > From: Benjamin Greenwald <beng@lcs.mit.edu> > Subject: New vx driver (Re: vx device (3c905-100mb) ) > > I might as well take this as an opportunity to announce that a new vx driver > is under development. I just received the technical docs from 3Com and should > have a good amount of time to sit down and hack this coming week. > > - -Ben Greenwald > > > The man page for the 'vx' device only mentions 10Mb support (in 2.2.2). > > Has this device been updated to support 100mbit yet? And if not is anyone > > working on updating it? I have time to work on the driver, but have done > > (very) little driver programming. > > I would like to run it at 100mbit-full-duplex, but it does not appear to > > be fully supported in this configuration. > > -James Flemer > > <flemer@tiger.acsu.k12.vt.us> > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 14:13:11 -0500 (EST) > From: "David E. Cross" <dec@phoenix.its.rpi.edu> > Subject: XTI (shudder) > > Are there any plans to migrate XTI(TLI) into the kernel or provide library > support for this 'standard'? > > - -- > David Cross > UNIX Systems Administrator > GE Corporate R&D > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 12:33:08 -0700 (MST) > From: Atipa <freebsd@atipa.com> > Subject: Re: New vx driver (Re: vx device (3c905-100mb) ) > > I have heard that those cards are architecturally unimpressive. What type > of performance do you expect? I have heard they are slower than the DECs > and Intels, especially for NFS traffic. Any comments? > > Kevin > > On Fri, 20 Mar 1998, Benjamin Greenwald wrote: > > > I might as well take this as an opportunity to announce that a new vx driver > > is under development. I just received the technical docs from 3Com and should > > have a good amount of time to sit down and hack this coming week. > > > > -Ben Greenwald > > > > > The man page for the 'vx' device only mentions 10Mb support (in 2.2.2). > > > Has this device been updated to support 100mbit yet? And if not is anyone > > > working on updating it? I have time to work on the driver, but have done > > > (very) little driver programming. > > > I would like to run it at 100mbit-full-duplex, but it does not appear to > > > be fully supported in this configuration. > > > -James Flemer > > > <flemer@tiger.acsu.k12.vt.us> > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 21:45:28 +0200 (SAT) > From: Robert Nordier <rnordier@iafrica.com> > Subject: Re: newmsdosfs anyone ? > > Luigi Rizzo wrote: > > > > The latest mtools works pretty well for large disks. > > > > 3.8 or later ? > > I used a 3.9 pre-release to test standalone FAT32 support I was doing > for sysinstall. Mtools did work correctly for FAT32 partitions > 0xffff > clusters, but I didn't really look at the whole package. > > [ ... ] > > I have patches (for mtools 3.0) to support HDs (but only up to 512MB) > > and make them bootable in DOS or Windows95 (you need a DOS/Win > > licence, and you need to grab the init files and boot sector and put > > them into /usr/local/lib/mtools... > > > > Would you be interested to integrate that as well ? > > If you're likely to use it, I guess it should be added. > > - -- > Robert Nordier > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 15:01:40 -0500 (EST) > From: "John S. Dyson" <toor@dyson.iquest.net> > Subject: Re: SCO (was Re: hi terry) > > > > Ron Minnich has been trying to shove his more-than-functional clustering > > > implementation into our laps for the last two or three years now. I > > > can hardly blame the guy for feeling distinctly ignored. > > > > Funny you should mention him since he just got in touch with me about > > this and I apologised for what most of -core feels is one of our more > > glaring failures to catch the ball. I think at this point that we > > should simply coerce Ron somehow (anybody know of any exploitable > > vices the guy has? :-) into joining -committers so that we're no > > longer a bottleneck for him. > > > I tend to trust Ron, BTW. > > John > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 15:11:29 -0500 (EST) > From: "John S. Dyson" <toor@dyson.iquest.net> > Subject: Re: mremap? > > > > ok, i'm not promising anything here, but if i implemented mremap(), would > > > there be any interest in allowing it into -current? > > > > > > mremap just allows for moving and resizing mmap'd segments. > > > > You're more than welcome to give it a try. I had a look at the way > > Linux does it, and frankly the layering violations were pretty shocking > > (although there appears to be a great deal less sophistication in their > > VM system). > > > > I couldn't see how to provide similar functionality with FreeBSD, but > > if you're willing to get a little close to the way that memory mapping > > works (check with David Greenman if you need advice here) you should be > > able to pull it off. > > > I was planning on implementing mremap. I am not sure of the api, but > it should be "easy" to implement with our current VM code. Think > of map entries as being the address space "chunks", and objects as being > the data repositorys. I want to foster others knowing how the code > works, so now I don't want to do it :-). It would take me about 4Hrs > to implement, and I want more people on the project to be able to > do this stuff. The initial learning curve is long, but after that, > there will be more people yet who know how the VM code works!!! :-). > > Think of it like this: > > First, remove the old map entries in the destination location. Perhaps > saving them for undoing the effects of this operation upon failure (if > needed by the API.) > > Next, grab the map entries in the source location, removing them, if > the API requires such. Otherwise copy them. When "grabbing" the > map entries, make sure that you trim them on both sides (trim the > address space chunks (entries).) > > Put the old map entries into the new place in the map, making sure > that the offsets are fixed up... > > When copying the map entries, it is important to make sure that the > state of the destination entries is correct. You'll have to UTSL to > see how to do that. > > This is little more complex than forking a process, but not > brain surgery... Our VM code as inherited from Mach, is extremely > flexible and really easy to work with. Take a look at the fork code > (vmspace_fork) for a slightly not applicable example of moving address > space entries (map entries) around. > > John > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 12:32:19 -0800 (PST) > From: Simon Shapiro <shimon@simon-shapiro.org> > Subject: Re: How do you increase available SYSV shared memory? > > On 18-Mar-98 Kent S. Gordon wrote: > > > >>>>>> "shimon" == Simon Shapiro <shimon@simon-shapiro.org> writes: > > I have been thinking of changing Postgres to use mmapped files instead > > of SYSV shared memory. I think this should allow for larger postgres > > This will be a disaster. It assumes that PostgreSQL uses files for data > storage. While this is the default mode, it is NOT the only storage > meanager. In PostgreSQL, like most true RDBMS, the storage of data is > decoupled from the logic of the relational model, etc. I am building a > storage manager that uses a totally different (distributed) storage model > than Unix files. A memory based storage manager already exists in > PostgreSQL. Please do not break these. > > Sion > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 15:26:04 -0500 > From: Benjamin Greenwald <beng@lcs.mit.edu> > Subject: Re: New vx driver (Re: vx device (3c905-100mb) ) > > I hadn't heard about any problems with NFS traffic. I've used these cards in > a mixed network with Sparc and PA-RISC workstations and I have to say I got at > least comparable NFS performance from the 3Com NIC's. > > The Intel cards are probably the best... they are certainly the most flexible. > As to the DEC cards, it is my understanding that they have alignment > restrictions (packets have to be long word aligned... therefore a copy is > required) that limit performance. > > I'm not saying the 3Com cards are the best out there. I _know_ there is a > great deal of improvement to be made (the card under Win NT screams), but just > how much I'm not going to attempt to quantify at this rather early date. The > truth is it doesn't matter. There are a lot of these cards out there and a > lot of people who run FreeBSD use them. Whatever performance we can suck out > of them, we should. If it turns out that the numbers are less impresive than > the Intel or DEC numbers, at least people can make a more informed decision > about purchasing because they'll be comparing apples to apples, not apples to > rotten acorns. For the rest of us who are stuck with what we've got, at least > we won't feel that rush of air and the sonic boom as the world passes us by. > > - -Ben > > > > > I have heard that those cards are architecturally unimpressive. What type > > of performance do you expect? I have heard they are slower than the DECs > > and Intels, especially for NFS traffic. Any comments? > > > > Kevin > > > > On Fri, 20 Mar 1998, Benjamin Greenwald wrote: > > > > > I might as well take this as an opportunity to announce that a new vx drive > r > > > is under development. I just received the technical docs from 3Com and sho > uld > > > have a good amount of time to sit down and hack this coming week. > > > > > > -Ben Greenwald > > > > > > > The man page for the 'vx' device only mentions 10Mb support (in 2.2.2). > > > > Has this device been updated to support 100mbit yet? And if not is anyone > > > > working on updating it? I have time to work on the driver, but have done > > > > (very) little driver programming. > > > > I would like to run it at 100mbit-full-duplex, but it does not appear to > > > > be fully supported in this configuration. > > > > -James Flemer > > > > <flemer@tiger.acsu.k12.vt.us> > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 22:19:31 +0100 > From: Eivind Eklund <eivind@yes.no> > Subject: Re: How do you increase available SYSV shared memory? > > On Fri, Mar 20, 1998 at 12:32:19PM -0800, Simon Shapiro wrote: > > > > On 18-Mar-98 Kent S. Gordon wrote: > > > > > >>>>>> "shimon" == Simon Shapiro <shimon@simon-shapiro.org> writes: > > > I have been thinking of changing Postgres to use mmapped files instead > > > of SYSV shared memory. I think this should allow for larger postgres > > > > This will be a disaster. It assumes that PostgreSQL uses files for data > > storage. While this is the default mode, it is NOT the only storage > > meanager. In PostgreSQL, like most true RDBMS, the storage of data is > > decoupled from the logic of the relational model, etc. I am building a > > storage manager that uses a totally different (distributed) storage model > > than Unix files. A memory based storage manager already exists in > > PostgreSQL. Please do not break these. > > I don't think you're quite getting him (or I'm not getting you at all). > mmap()ing /dev/zero is a common way of getting hold of shared memory, > instead of using the SYSV SHMEM extension. mmap'ing usually works better. > > This is just replacing one technique for getting hold of shared memory with > another; it does nothing to the storage manager. > > Eivind. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 16:29:34 -0500 (EST) > From: "David E. Cross" <dec@phoenix.its.rpi.edu> > Subject: Re: How do you increase available SYSV shared memory? > > On Fri, 20 Mar 1998, Eivind Eklund wrote: > > > On Fri, Mar 20, 1998 at 12:32:19PM -0800, Simon Shapiro wrote: > > > > > > On 18-Mar-98 Kent S. Gordon wrote: > > > > > > > >>>>>> "shimon" == Simon Shapiro <shimon@simon-shapiro.org> writes: > > > > I have been thinking of changing Postgres to use mmapped files instead > > > > of SYSV shared memory. I think this should allow for larger postgres > > > > > > This will be a disaster. It assumes that PostgreSQL uses files for data > > > storage. While this is the default mode, it is NOT the only storage > > > meanager. In PostgreSQL, like most true RDBMS, the storage of data is > > > decoupled from the logic of the relational model, etc. I am building a > > > storage manager that uses a totally different (distributed) storage model > > > than Unix files. A memory based storage manager already exists in > > > PostgreSQL. Please do not break these. > > > > I don't think you're quite getting him (or I'm not getting you at all). > > mmap()ing /dev/zero is a common way of getting hold of shared memory, > > instead of using the SYSV SHMEM extension. mmap'ing usually works better. > > > > This is just replacing one technique for getting hold of shared memory with > > another; it does nothing to the storage manager. > > This is very common indeed, it is how the dynamic linker on solaris works. > > - -- > David Cross > UNIX Systems Administrator > GE Corporate R&D > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 14:07:54 -0800 (PST) > From: Simon Shapiro <shimon@simon-shapiro.org> > Subject: Re: How do you increase available SYSV shared memory? > > On 20-Mar-98 Eivind Eklund wrote: > > On Fri, Mar 20, 1998 at 12:32:19PM -0800, Simon Shapiro wrote: > >> > >> On 18-Mar-98 Kent S. Gordon wrote: > >> > > >> >>>>>> "shimon" == Simon Shapiro <shimon@simon-shapiro.org> writes: > >> > I have been thinking of changing Postgres to use mmapped files instead > >> > of SYSV shared memory. I think this should allow for larger postgres > >> > >> This will be a disaster. It assumes that PostgreSQL uses files for data > >> storage. While this is the default mode, it is NOT the only storage > >> meanager. In PostgreSQL, like most true RDBMS, the storage of data is > >> decoupled from the logic of the relational model, etc. I am building a > >> storage manager that uses a totally different (distributed) storage > >> model > >> than Unix files. A memory based storage manager already exists in > >> PostgreSQL. Please do not break these. > > > > I don't think you're quite getting him (or I'm not getting you at all). > > mmap()ing /dev/zero is a common way of getting hold of shared memory, > > instead of using the SYSV SHMEM extension. mmap'ing usually works > > better. > > > > This is just replacing one technique for getting hold of shared memory > > with > > another; it does nothing to the storage manager. > > Apologies then. I thought the intention was to mmap the storage manager. > I am still recovering from a nasty cold and an all-night flight back home. > The trip was worht it, though :-) > > - ---------- > > > Sincerely Yours, > > Simon Shapiro > Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 16:16:11 -0600 > From: Jonathan Lemon <jlemon@americantv.com> > Subject: Re: mremap? > > On Mar 03, 1998 at 03:11:29PM -0500, John S. Dyson wrote: > > I was planning on implementing mremap. I am not sure of the api, but > > it should be "easy" to implement with our current VM code. Think > > of map entries as being the address space "chunks", and objects as being > > the data repositorys. I want to foster others knowing how the code > > works, so now I don't want to do it :-). It would take me about 4Hrs > > to implement, and I want more people on the project to be able to > > do this stuff. The initial learning curve is long, but after that, > > there will be more people yet who know how the VM code works!!! :-). > > I have something similar to this, but slightly different: > > I want to be able to map part of an address space of one process > into the address space of a different process, at a different location, > resulting in shared memory between the processes. > > (Why? I wanted a "vm86" process, with 1MB mapped starting at address 0, > and the same region mapped into the "control" process, at a different > location.) > > EG: > boolean_t > vm_map_shared(smap, dmap, saddr, daddr, size) > vm_map_t smap, dmap; > vm_offset_t saddr, daddr; > vm_size_t size; > > Would this type of routine be useful? > - -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 17:38:01 -0500 (EST) > From: "John S. Dyson" <toor@dyson.iquest.net> > Subject: Re: mremap? > > > On Mar 03, 1998 at 03:11:29PM -0500, John S. Dyson wrote: > > > I was planning on implementing mremap. I am not sure of the api, but > > > it should be "easy" to implement with our current VM code. Think > > > of map entries as being the address space "chunks", and objects as being > > > the data repositorys. I want to foster others knowing how the code > > > works, so now I don't want to do it :-). It would take me about 4Hrs > > > to implement, and I want more people on the project to be able to > > > do this stuff. The initial learning curve is long, but after that, > > > there will be more people yet who know how the VM code works!!! :-). > > > > I have something similar to this, but slightly different: > > > > I want to be able to map part of an address space of one process > > into the address space of a different process, at a different location, > > resulting in shared memory between the processes. > > > > (Why? I wanted a "vm86" process, with 1MB mapped starting at address 0, > > and the same region mapped into the "control" process, at a different > > location.) > > > > EG: > > boolean_t > > vm_map_shared(smap, dmap, saddr, daddr, size) > > vm_map_t smap, dmap; > > vm_offset_t saddr, daddr; > > vm_size_t size; > > > > Would this type of routine be useful? > > > I suspect that it would be useful, given a "use." I don't know enough > about exactly what the userland API would/should look like (re: security, > and features) to implement it "off the top of my head." > > If there is a reasonable justification for a new system call or equiv, > I am all for it!!! > > John > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 14:39:40 -0800 > From: Studded <Studded@dal.net> > Subject: Re: Discussion about script to update /etc, etc. > > Jordan K. Hubbard wrote: > > [design model snipped] > > > As the author of a number of the temporary bodges we're using right > > now (/etc/rc.conf and friends), I can say that they're exactly that - > > temporary bodges with numerous limitations. I was hoping we'd stop > > hacking out ever more temporary solutions to the /etc configuration > > problem someday and start thinking of something that actually SCALES > > worth a damn, but we clearly haven't gotten to that point yet. :) > > Ok, go ahead and close the PR. If I read between the lines it sounds to > me like you don't want this as a port either, however if I'm incorrect > in that assumption please let me know and I'll see what I can do about > getting it done before the deadline. > > I agree that a better solution is desirable, I made that point myself. > If I were capable of putting together something along the lines of what > you want I would be happy to do so. However it seems to me that some > solution is better than no solution, especially when you consider that > there is currently nothing in the base that explains how to do the > upgrade properly. > > Doug > > - -- > *** Chief Operations Officer, DALnet IRC network *** > *** Proud operator, designer and maintainer of the world's largest > *** Internet Relay Chat server. 5,328 clients and still growing. > *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 16:53:53 -0600 > From: Jonathan Lemon <jlemon@americantv.com> > Subject: Re: mremap? > > On Mar 03, 1998 at 05:38:01PM -0500, John S. Dyson wrote: > > > On Mar 03, 1998 at 03:11:29PM -0500, John S. Dyson wrote: > > > > I was planning on implementing mremap. I am not sure of the api, but > > > > it should be "easy" to implement with our current VM code. Think > > > > of map entries as being the address space "chunks", and objects as being > > > > the data repositorys. I want to foster others knowing how the code > > > > works, so now I don't want to do it :-). It would take me about 4Hrs > > > > to implement, and I want more people on the project to be able to > > > > do this stuff. The initial learning curve is long, but after that, > > > > there will be more people yet who know how the VM code works!!! :-). > > > > > > I have something similar to this, but slightly different: > > > > > > I want to be able to map part of an address space of one process > > > into the address space of a different process, at a different location, > > > resulting in shared memory between the processes. > > > > > > (Why? I wanted a "vm86" process, with 1MB mapped starting at address 0, > > > and the same region mapped into the "control" process, at a different > > > location.) > > > > > > EG: > > > boolean_t > > > vm_map_shared(smap, dmap, saddr, daddr, size) > > > vm_map_t smap, dmap; > > > vm_offset_t saddr, daddr; > > > vm_size_t size; > > > > > > Would this type of routine be useful? > > > > > I suspect that it would be useful, given a "use." I don't know enough > > about exactly what the userland API would/should look like (re: security, > > and features) to implement it "off the top of my head." > > Oh, I've already have this running, and it's just for internal kernel > use at the moment (no userspace API). What I was really asking was if > this might be useful to a wider audience, and if the semantics aren't > too seriously deranged. > - -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 15:16:57 +0000 > From: "Jeff Buseman" <jeff@netronix.com> > Subject: (Fwd) Re: Natd Support for Microsoft PPTP / VPN using protocol > > Eivind, > > Thank you for your reponse. > > > It only handle TCP and UDP traffic. The only way to get it to handle > > something else is by asking Charles or me to make libalias do so, preferably > > with pointer to suitable documentation. I might find time to handle this > > fairly quickly if you come up with docs. > > I see that others have sent you some references, and I'm including > my summary of what I've found so far below. I have someone who would > be willing to try to capture some packets on the incoming side, if > that would help. If you need anything else that I could do, let me > know. Thanks again. > > PPTP Documentation > > RFC's describing the GRE protocol > http://www.es.net/pub/rfcs/rfc1701.txt > http://www.es.net/pub/rfcs/rfc1702.txt > > Draft Proposal for PPTP > ftp://ietf.org/internet-drafts/draft-ietf-pppext-pptp-02.txt > http://www.microsoft.com/communications/exes/draft-ietf-pppext-p > ptp-01.txt > > Linux program for protocol redirection (including protocol 47) > http://bmrc.berkeley.edu/people/chaffee/linux_pptp.html > http://www.pdos.lcs.mit.edu/~cananian/Projects/IPfwd/ > > Microsoft Documentation on PPTP > Index: http://www.microsoft.com/communications/morepptp.htm > > Microsoft Dial-Up Networking Documentation (DUN12.DOC) > http://support.microsoft.com/support/kb/articles/Q166/2/88.asp > (Section 4 briefly describes PPTP / Firewalls) > > > Jeff Buseman > jeff@netronix.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 18:27:49 -0500 (EST) > From: "John S. Dyson" <toor@dyson.iquest.net> > Subject: Re: mremap? > > > On Mar 03, 1998 at 05:38:01PM -0500, John S. Dyson wrote: > > > > On Mar 03, 1998 at 03:11:29PM -0500, John S. Dyson wrote: > > > > > I was planning on implementing mremap. I am not sure of the api, but > > > > > it should be "easy" to implement with our current VM code. Think > > > > > of map entries as being the address space "chunks", and objects as being > > > > > the data repositorys. I want to foster others knowing how the code > > > > > works, so now I don't want to do it :-). It would take me about 4Hrs > > > > > to implement, and I want more people on the project to be able to > > > > > do this stuff. The initial learning curve is long, but after that, > > > > > there will be more people yet who know how the VM code works!!! :-). > > > > > > > > I have something similar to this, but slightly different: > > > > > > > > I want to be able to map part of an address space of one process > > > > into the address space of a different process, at a different location, > > > > resulting in shared memory between the processes. > > > > > > > > (Why? I wanted a "vm86" process, with 1MB mapped starting at address 0, > > > > and the same region mapped into the "control" process, at a different > > > > location.) > > > > > > > > EG: > > > > boolean_t > > > > vm_map_shared(smap, dmap, saddr, daddr, size) > > > > vm_map_t smap, dmap; > > > > vm_offset_t saddr, daddr; > > > > vm_size_t size; > > > > > > > > Would this type of routine be useful? > > > > > > > I suspect that it would be useful, given a "use." I don't know enough > > > about exactly what the userland API would/should look like (re: security, > > > and features) to implement it "off the top of my head." > > > > Oh, I've already have this running, and it's just for internal kernel > > use at the moment (no userspace API). What I was really asking was if > > this might be useful to a wider audience, and if the semantics aren't > > too seriously deranged. > > > It looks okay, I wouldn't mind if it was added :-). I would support > adding it. There is absolutely no reason for me to stand in the way > of progress!!! > > John > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 18:56:00 -0500 > From: Ken Key <key@cs.utk.edu> > Subject: Need Intel 82557/82558 Ethernet docs to hack if_fxp. > > Hi folks, > > I want to try a slightly sick hack to the if_fxp driver and am having > a devil of a time finding adequate programming docs for the Intel 82557 > or 82558 LAN controller. I've pulled the data sheets off of Intel's > developer web-site but it skips completely over the actual device driver > interface and refers to the "82557 Users Manual", that I cannot find > a reference to at their site. Does anyone know how a mere mortal may > obtain a copy of this manual to hack on the if_fxp? > > Thanks, > Ken Key (key@cs.utk.edu) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 13:23:37 -0500 > From: sbabkin@dcn.att.com > Subject: FW: Digi Exp > > Sorry, I tried to send this message personally but it was not > delivered. I think it's not to far from -hackers subject. > > > ---------- > > From: Babkin, Serge > > Sent: Friday, March 20, 1998 1:20 PM > > To: 'decebal@moldnet.md' > > Subject: RE: Digi Exp > > > > ---------- > > From: decebal@moldnet.md[SMTP:decebal@moldnet.md] > > > > On Fri, 20 Mar 1998, Alfred Perlstein wrote: > > > > > no, you can't do this, are you sure we don't support this? > > > > > > > Yes FreeBSD doesn't support Xem. > > FreeBSD suport Xe board that is not like Xem. > > I compiled Xe driver and kernel was not able to init the board. > > > > Well, Linux has sources for Digi Xem and all Digi boards for all buses > > but i am just beginer and will not be able to port them to FreeBSD. > > > > In this case it must be not that difficult provided that > > the FreeBSD driver (yes, originally written by me) was > > originally based on Linux driver and although many > > things were redesigned, the > > major structure is probably still like Linux. If it's not > > then perhaps it's time to drop the GNU-style copyright > > from it :-) > > > > -SB > > > > P.S. Personally I'm not going to add Xem support for BSD because I > > have now no Digi card and, yet worse, I have no motivation to do that. > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sat, 21 Mar 1998 13:14:22 +1100 > From: David Dawes <dawes@rf900.physics.usyd.edu.au> > Subject: Re: 3.0-971225SNAP, Japanese/Korean locales, and libxpg4 > > On Tue, Mar 17, 1998 at 11:42:31AM +0900, Makoto MATSUSHITA wrote: > > > >Sorry I do not know why multibyte-supporting locale is out of libc... > > > >k.keithley> What's the rationale for having the SJIS and EUC locale > >k.keithley> support in libxpg4 instead of libc? > > > >IMHO, we should link with xpg4 library when linking X libraries to > >compile X application. Many FreeBSD ports application tries to link > >so, especially in japanese and x11 category (these applications try to > >link xpg4 library manually; ahh, where the imake framework has gone :-) > > > >How about changing $XTOP/X11/lib/config/FreeBSD.cf to add -lxpg4 > >to linker's option, when the FreeBSD's version >= 2.2 ? > > So, what's the official position of FreeBSD on this? If it is going to > stay in libxpg4 rather than be in libc, I'll make the appropriate change > to the FreeBSD.cf in the XFree86 source. Perhaps something like the > following (relative to XFree86 3.3.2)? > > > *** FreeBSD.cf 1998/03/01 01:08:59 3.58.2.11 > - --- xc/config/cf/FreeBSD.cf 1998/03/21 02:12:22 > *************** > *** 59,65 **** > - --- 59,70 ---- > #define DefaultCCOptions -ansi -pedantic -Dasm=__asm > #endif > #ifndef ExtraLibraries > + /* support for multi-byte locales is in libxpg4 rather than libc */ > + #if OSMajorVersion > 2 || (OSMajorVersion == 2 && OSMinorVersion >= 2) > + #define ExtraLibraries -lxpg4 > + #else > #define ExtraLibraries /**/ > + #endif > #endif > #ifndef UseGnuMalloc > /* 2.2 doesn't really have GnuMalloc */ > > > David > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 21:19:30 -0800 > From: Joe McGuckin <joe@via.net> > Subject: fxp strange problem > > I have had odd problems with a number of fxp cards. I'm using 2.2.5-RELEASE. > > I have a machine that refuses to work if I plug it into a BAY 350T 10/100 > ethernet switch. I don't even get status or link lights. If I plug it into > a 10Mb ethernet hub, it works fine. > > Any ideas ? > > Joe > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sat, 21 Mar 1998 00:32:23 -0500 > From: "Alfred Perlstein" <perlsta@cs.sunyit.edu> > Subject: Re: mremap? > > wouldn't a simple resolution lie in just "locking" the kernel, unmapping the > segment and seeing if it was possible to remap it according to the user's > wishes then mmap it again the unlock the kernel? in SMP situations if the > request for a remap fialed right after the unmap we could check if the user > specified the "unmoveable flag" and then remap as/if nessesary. > > > maybe this isn't the most effecient method.. but i makes sense to someone > who hasn't even looked at the sources yet in regards to implementing this. > > i'm looking at your proposals for mremap() right after i send this. > > - -Alfred > > > >-----Original Message----- > >From: John S. Dyson <toor@dyson.iquest.net> > >To: Mike Smith <mike@smith.net.au> > >Cc: perlsta@cs.sunyit.edu <perlsta@cs.sunyit.edu>; hackers@FreeBSD.ORG > ><hackers@FreeBSD.ORG> > >Date: Friday, March 20, 1998 11:13 AM > >Subject: Re: mremap? > > > > > >>> > ok, i'm not promising anything here, but if i implemented mremap(), > >would > >>> > there be any interest in allowing it into -current? > >>> > > >>> > mremap just allows for moving and resizing mmap'd segments. > >>> > >>> You're more than welcome to give it a try. I had a look at the way > >>> Linux does it, and frankly the layering violations were pretty shocking > >>> (although there appears to be a great deal less sophistication in their > >>> VM system). > >>> > >>> I couldn't see how to provide similar functionality with FreeBSD, but > >>> if you're willing to get a little close to the way that memory mapping > >>> works (check with David Greenman if you need advice here) you should be > >>> able to pull it off. > >>> > >>I was planning on implementing mremap. I am not sure of the api, but > >>it should be "easy" to implement with our current VM code. Think > >>of map entries as being the address space "chunks", and objects as being > >>the data repositorys. I want to foster others knowing how the code > >>works, so now I don't want to do it :-). It would take me about 4Hrs > >>to implement, and I want more people on the project to be able to > >>do this stuff. The initial learning curve is long, but after that, > >>there will be more people yet who know how the VM code works!!! :-). > >> > >>Think of it like this: > >> > >>First, remove the old map entries in the destination location. Perhaps > >>saving them for undoing the effects of this operation upon failure (if > >>needed by the API.) > >> > >>Next, grab the map entries in the source location, removing them, if > >>the API requires such. Otherwise copy them. When "grabbing" the > >>map entries, make sure that you trim them on both sides (trim the > >>address space chunks (entries).) > >> > >>Put the old map entries into the new place in the map, making sure > >>that the offsets are fixed up... > >> > >>When copying the map entries, it is important to make sure that the > >>state of the destination entries is correct. You'll have to UTSL to > >>see how to do that. > >> > >>This is little more complex than forking a process, but not > >>brain surgery... Our VM code as inherited from Mach, is extremely > >>flexible and really easy to work with. Take a look at the fork code > >>(vmspace_fork) for a slightly not applicable example of moving address > >>space entries (map entries) around. > >> > >>John > >> > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 23:48:28 -0600 > From: Dan Nelson <dnelson@emsphone.com> > Subject: Re: fxp strange problem > > In the last episode (Mar 20), Joe McGuckin said: > > > > > > I have had odd problems with a number of fxp cards. I'm using > > 2.2.5-RELEASE. > > > > I have a machine that refuses to work if I plug it into a BAY 350T > > 10/100 ethernet switch. I don't even get status or link lights. If I > > plug it into a 10Mb ethernet hub, it works fine. > > I've seen this happen on 350T's also. Try forcing one or both ends > (the card via ifconfig media, or the 350T via the telnet interface) to > the speed you want and see if that helps. > > -Dan Nelson > dnelson@emsphone.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 22:25:25 -0800 > From: Joe McGuckin <joe@via.net> > Subject: inetd in realloc():warning:junk pointer, towo low to make sense. > > What causes this? It seems to unrecoverable. Inetd must be restarted > by hand. > > - -joe > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sat, 21 Mar 1998 01:45:04 -0500 (EST) > From: "John S. Dyson" <toor@dyson.iquest.net> > Subject: Re: inetd in realloc():warning:junk pointer, towo low to make sense. > > > > > What causes this? It seems to unrecoverable. Inetd must be restarted > > by hand. > > > I have seen the problem when running a buggered version of -current. If > you are running a current between 13-mar and 20-mar, you could be hosing > your filesystems. > > John > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Fri, 20 Mar 1998 21:38:12 +0100 (MET) > From: Wilko Bulte <wilko@yedi.iaf.nl> > Subject: Re: netscape4 weirdness: what is happening here?? > > As Randall Hopper wrote... > > Wilko Bulte: > > |I'm running Netscape 4 on my 2.2.5R box. Every now and then it refuses to > > |start properly. It just loops, consuming CPU. > > | > > | 979 netscape.bin CALL gettimeofday(0xefbfa4f0,0) > > | 979 netscape.bin RET gettimeofday 0 > > | 979 netscape.bin CALL sigreturn(0xefbfa5b8) > > | 979 netscape.bin RET sigreturn JUSTRETURN > > | 979 netscape.bin PSIG SIGALRM caught handler=0x76cdf8 mask=0x0 code=0x0 > > ... > > | > > |This repeats forever. FWIW this happens both with and without the ISDN/ppp > > |link to the Internet. > > > > Ollivier Robert: > > |export XCMSDB; XCMSDB=/dev/null > > > > garman@earthling.net: > > |More simply, every time this happened to me, I found that removing the line: > > | > > |user_pref("browser.startup.license_accepted", "1000 4.04"); > > FWIW: the fix Ollivier suggested seems to do the trick for me. > > Netscape seems to be a truly weird program. %-) > > Wilko > _ ______________________________________________________________________ > | / o / / _ Bulte email: wilko @ yedi.iaf.nl > |/|/ / / /( (_) Arnhem, The Netherlands WWW: http://www.tcja.nl > - ---------------------------------------------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sat, 21 Mar 1998 17:05:31 +0100 (CET) > From: Andrzej Bialecki <abial@nask.pl> > Subject: ANNOUNCE: PicoBSD 0.31 > > Hi! > > I am pleased to announce that PicoBSD version 0.31 is available. This is a > version of FreeBSD fitting on a single floppy - it can serve as a > dialup-access tool (includes SSH, telnet and FTP clients), or as a small > router replacement (includes IP firewall and SNMP agent). Visit > > http://www.freebsd.org/~abial > > for further information and download. > > Have fun! > > Andrzej Bialecki > > - ---------------------+------------------------------------------------------ --- > abial@warman.org.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } > Research & Academic | "Be open-minded, but don't let your brains to fall out." > Network in Poland | All of the above (and more) is just my personal opinion. > - ---------------------+------------------------------------------------------ --- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Sat, 21 Mar 1998 21:48:27 +0000 (GMT) > From: Terry Lambert <tlambert@primenet.com> > Subject: Re: How do you increase available SYSV shared memory? > > > > > > I have been thinking of changing Postgres to use mmapped files instead > > > > > of SYSV shared memory. I think this should allow for larger postgres > > > > > > > > This will be a disaster. It assumes that PostgreSQL uses files for data > > > > storage. While this is the default mode, it is NOT the only storage > > > > meanager. In PostgreSQL, like most true RDBMS, the storage of data is > > > > decoupled from the logic of the relational model, etc. I am building a > > > > storage manager that uses a totally different (distributed) storage model > > > > than Unix files. A memory based storage manager already exists in > > > > PostgreSQL. Please do not break these. > > > > > > I don't think you're quite getting him (or I'm not getting you at all). > > > mmap()ing /dev/zero is a common way of getting hold of shared memory, > > > instead of using the SYSV SHMEM extension. mmap'ing usually works better. > > > > > > This is just replacing one technique for getting hold of shared memory with > > > another; it does nothing to the storage manager. > > > > This is very common indeed, it is how the dynamic linker on solaris works. > > > As a point of interest, virtual memory *without* a backing object > works *significantly* faster than virtual memory *with* a backing > object. > > This should be pretty obvious from simple observation of what a > backing object means: it means that you must maintain write-through > cache coherency for the object, going through the VFS code to do it. > > There are a number of large wins you could wring out of the VFS code > that FreeBSD may be on the road to wringing, but a backing object > still tends to nail flodding after the high water-mark to the speed > of the pager (either the swap pager (which is fast) or the vnode > pager (which is less fast). > > I think John Dyson did significant work to speed up anonymous shared > memory. I *think* it should work with /dev/zero, but of course, you > would have to implement some mechanism of region sharing on top of > that (/dev/zero pages are copy-on-write, and would only be shared by > child processes, and then only in specific rfork circumstances). > > > That said, I believe there are currently reasons, until you can use > a procfs call to adopt a copy-on-write region as a non-copy-on-write > region in another process (ie: copy the pages if they are /dev/zero > pages, but share them otherwise), that SYSV SHMEM is actually a > better (in terms of performance) technology. > > > Terry Lambert > terry@lambert.org > - --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > End of freebsd-hackers-digest V4 #75 > ************************************ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803220130.RAA06352>