Re: Kernel hacker tasks seek interested hackers
On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Narvi writes: On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: [snip] 7. [medium] The current naming for ptys doesn't scale that well. Changing it to ttyp%d / pty%d would probably be a good idea in the long run, but the ramifications are relatively widespread (think: "ports") Which while being scaleable in one direction (you can have things like /dev/pty1234567890) as it is essentialy open ended, on the other hand: a) pty/tty names are now variable length b) the name length advances quite quickly as we add more ptys c) it is a totaly new "look and feel" So why not instead: I think that is needlessly complicated. It's a direct extension to the present tty naming scheme. I think tty%05d would solve all but the third of your objections, The first was more a question of radix, implying that 10 might be too low. IMHO base-32 has many good qualities to itself. It makes retaining the policy of creating ptys in increments of 32 easy, the name space does not grow as fast (pty allows for more ptys than pty%06d) and it is not much different from the naming system. and quite frankly the "we've never done that before" argument works badly with me. It's more the argument of "why do it *significantly* differently from others?" -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message [EMAIL PROTECTED], Narvi writes: I think that is needlessly complicated. It's a direct extension to the present tty naming scheme. That doesn't automatically imply that it is a good idea :-) I think tty%05d would solve all but the third of your objections, The first was more a question of radix, implying that 10 might be too low. You know, then make it tty%012d and pretty much everybody on this planet should be happy, right ? IMHO base-32 has many good qualities to itself. It makes retaining the policy of creating ptys in increments of 32 easy, the name space does not grow as fast (pty allows for more ptys than pty%06d) and it is not much different from the naming system. There is no "policy of creating ptys in increments of 32" that I know of. /dev/MAKEDEV does it that way, but it is neither a policy nor desirable in my mind. I would far rather have it like tun, bpf and other sane pseudodevices: sh MAKEDEV pty200 # Make me 200 ptys. and quite frankly the "we've never done that before" argument works badly with me. It's more the argument of "why do it *significantly* differently from others?" Run that by me again: what is it ptys are called under Solaris, HPUX, AIX, generic SVR4 etc etc ? I think your suggestion belongs in the Obfuscated Sysadm Contest, not in FreeBSD. I'm also pretty convinced based on your past performances that you intend to argue this point until cows evolve into birds, so expect no more emails from me on this subject. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message [EMAIL PROTECTED], Marcel Moolenaar writes: Hi, There're a couple of variables in the Linuxulator that can be put under sysctl. These include the kernel version and the OSS version, among probably others. The question is simply were in the MIB to put them? 1) under "kern.linux" 2) under "kern.emu.linux" 3) under "linux" I vote for 3. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pex5 and xie load errors
On Sat, 14 Aug 1999, Randy Bush wrote: i just upgraded to current. i still have the following in my /etc/XF86Config Section "Module" Load"pex5.so" Load"xie.so" EndSection during X startup i get load errors for these. but i can see nothing unappy with X. do i delete them from /etc/XF86Config or rebuild X or what? Rebuilding X won't help last I tried. They have been broken for quite some time now. Seems there aren't enough people who care enough. thanks. randy Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pex5 and xie load errors
On Sun, 15 Aug 1999, Narvi wrote: On Sat, 14 Aug 1999, Randy Bush wrote: during X startup i get load errors for these. but i can see nothing unappy with X. do i delete them from /etc/XF86Config or rebuild X or what? Rebuilding X won't help last I tried. They have been broken for quite some time now. Seems there aren't enough people who care enough. Well, by "they" I hope you don't intend to mean modules in general. I am happily using my Riva TNT with XFree86 3.3.3.1, which is a module (the GLX): Section "Module" Load "glx.so" EndSection (**) stands for supplied, (--) stands for probed/default values (--) no ModulePath specified using default: /usr/X11R6/lib/modules GLX extension module for XFree86 3.3.3.1 -- Mesa version 3.0 GLX package version 0.9, GLX protocol version 1.2. (**) module glx.so successfully loaded from /usr/X11R6/lib/modules So what are the specific errors you get? randy Sander There is no love, no good, no happiness and no future - all these are just illusions. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message [EMAIL PROTECTED], "Brian F. Feldman" writes: On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: The question is simply were in the MIB to put them? ... 3) under "linux" I vote for 3. I suppose, but wouldn't the proper place be under machdep? I agree that a linux top-level MIB would be easiest to remember. We may have to emulate linux on other platforms as well... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
Hi, There're a couple of variables in the Linuxulator that can be put under sysctl. These include the kernel version and the OSS version, among probably others. The question is simply were in the MIB to put them? 1) under "kern.linux" 2) under "kern.emu.linux" 3) under "linux" 4) non of the above, because... kern.abi.linux or kern.compat.linux. We're staying away from the term "emulation" because it's being associated with things like the abominable 'lxrun' and virtual-machine emulators like VMware. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
"MS" == Mike Smith [EMAIL PROTECTED] writes: "MS" == Mike Smith [EMAIL PROTECTED] writes: Then after 5 seconds the screen blanks, the power light starts flashing (indicating suspend mode), but when I hit a key, the console says (slept 00:00:02) only, and programs in fact continued running (thus it didn't go or remain in suspend mode at all). MS I think you'll find that programs didn't, in fact, continue MS running; rather they paused and then resumed when you came out MS of suspend. I'm running seti@home, and it really continued while my computer was 'suspended'. Also a little test program continued running. MS What you're failing to offer here, and thus why I remain MS skeptical, is any evidence that suggests that these programs MS were "running" while the system believed itself to be MS suspended. I can see that after one hour of 'suspend' mode, the program has done for one hour worth of calculations. Really, I am not insane and know when my programs have run and done work and when not. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make cvsup broken
=== Cleaning for cvsup-16.0 To build this port without X11 (and without the GUI), define "NO_X11". cvsup-16.0.tar.gz doesn't seem to exist on this system. Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/. Receiving cvsup-16.0.tar.gz (342698 bytes): 100% 342698 bytes transferred in 6.7 seconds (49.86 Kbytes/s) === Extracting for cvsup-16.0 Checksum OK for cvsup-16.0.tar.gz. === cvsup-16.0 depends on executable: m3build-6 - found === cvsup-16.0 depends on shared library: m3.6 - found === Patching for cvsup-16.0 === Configuring for cvsup-16.0 === Building for cvsup-16.0 mkdir FreeBSD2 --- building in FreeBSD2 --- === suptcp m3build mkdir FreeBSD2 --- building in FreeBSD2 --- m3 -w1 -why -O -a libsuptcp.a -F/var/tmp/qkG99460 new source - compiling ../src/common/SupConnFD.i3 new source - compiling ../src/common/SupTCP.i3 new source - compiling ../src/POSIX/SupTCPPosix.i3 new source - compiling ../src/POSIX/SupTCPHack.i3 new source - compiling ../src/POSIX/SockOpt.i3 new source - compiling ../src/common/TCPMisc.i3 new source - compiling ../src/common/SupConnRW.i3 new source - compiling ../src/POSIX/SupTCP.m3 new source - compiling ../src/POSIX/SupTCPHackNull.m3 new source - compiling ../src/POSIX/SockOptFBSD.m3 new source - compiling ../src/common/SupConnRW.m3 - archiving libsuptcp.a === suplib m3build mkdir FreeBSD2 --- building in FreeBSD2 --- m3 -w1 -why -O -a libsuplib.a -F/var/tmp/qkH99492 new source - compiling ../src/FreeBSD/FileAttrOS.i3 new source - compiling ../src/FreeBSD/UProcTitle.i3 new source - compiling ../src/FreeBSD/UProcTitle.c new source - compiling ../src/libglob/fnmatch.c new source - compiling ../src/Uglob.i3 new source - compiling ../src/PathComp.i3 new source - compiling ../src/ChannelMux.i3 new source - compiling ../src/Logger.i3 new source - compiling ../src/LoggerClass.i3 new source - compiling ../src/SplitLogger.i3 new source - compiling ../src/SysLogger.i3 new source - compiling ../src/TimeStampLogger.i3 new source - compiling ../src/WrLogger.i3 new source - compiling ../src/ProcTitle.i3 new source - compiling ../src/Ugzip.i3 new source - compiling ../src/UgzipP.i3 new source - compiling ../src/Umd5.i3 new source - compiling ../src/MySyslog.i3 new source - compiling ../src/WatchDog.i3 new source - compiling ../src/IOWatchDog.i3 new source - compiling ../src/MD5Digest.i3 new source - compiling ../src/MD5.i3 new source - compiling ../src/AuthMD5.i3 new source - compiling ../src/TokScan.i3 new source - compiling ../src/DevT.i3 new source - compiling ../src/FileAttr.i3 new source - compiling ../src/FileAttrRep.i3 new source - compiling ../src/FileID.i3 new source - compiling ../src/CVProto.i3 new source - compiling ../src/EscapedRd.i3 new source - compiling ../src/EscapedWr.i3 new source - compiling ../src/MD5Wr.i3 new source - compiling ../src/ErrMsg.i3 new source - compiling ../src/DirEntry.i3 new source - compiling DirEntryList.i3 new source - compiling DirEntryListSort.i3 new source - compiling ../src/Glob.i3 new source - compiling ../src/GlobTree.i3 new source - compiling ../src/LockFile.i3 new source - compiling ../src/ExecRec.i3 new source - compiling ExecRecSeq.i3 new source - compiling ExecRecSeqRep.i3 new source - compiling ../src/RCSError.i3 new source - compiling ../src/RCSString.i3 new source - compiling ../src/RCSPhrase.i3 new source - compiling ../src/RCSPhrases.i3 new source - compiling ../src/RCSDate.i3 new source - compiling ../src/RCSRevNum.i3 new source - compiling ../src/RCSTag.i3 new source - compiling RCSTagList.i3 new source - compiling RCSTagListSort.i3 new source - compiling ../src/RCSEdit.i3 new source - compiling RCSEditTbl.i3 new source - compiling SortedRCSEditTbl.i3 new source - compiling ../src/RCSDelta.i3 new source - compiling ../src/RCSKeyword.i3 new source - compiling RCSDeltaTbl.i3 new source - compiling ../src/RCSFile.i3 new source - compiling RCSDeltaList.i3 new source - compiling ../src/RCSDeltaClass.i3 new source - compiling RCSDeltaListSort.i3 new source - compiling SortedRCSDeltaTbl.i3 new source - compiling ../src/SupFileRec.i3 new source - compiling ../src/SupMisc.i3 new source - compiling ../src/FileStatus.i3 new source - compiling ../src/FileStatusRaw.i3 new source - compiling ../src/StatusFile.i3 new source - compiling ../src/CVTree.i3 new source - compiling ../src/GzipError.i3 new source - compiling ../src/GzipRd.i3 new source - compiling ../src/GzipWr.i3 new source - compiling ../src/RsyncBlock.i3 new source - compiling RsyncBlockArraySort.i3 new source - compiling ../src/RsyncFile.i3 new source - compiling ../src/Reaper.i3 new source - compiling ../src/SigHandler.i3 new source - compiling ../src/UnixMisc.i3 new source - compiling ../src/UnixMiscC.c new source - compiling ../src/Attic.i3 new source - compiling ../src/FreeBSD/FileAttrOS.m3 new source - compiling ../src/FreeBSD/ProcTitle.m3 new source - compiling ../src/PathComp.m3 new source - compiling ../src/ChannelMux.m3 new source -
Re: make of vic broken in current
excuse previous gibberish. i am at a loss as to how it happened, maybe vm dealing with a very long line. i hope it is not reproducable. -current as of 99.08.14 could it be the compiler was upgraded recently ? I wrote grabber-x11.cc but i am far from being C++ literate so the most i could do is check that it would compile on the platform i was using (2.2.x at the time). Some review and cleanup from someone who knows C++ would be very welcome. cheers luigi c++ -O2 -DUSE_SHM -DED_YBITS=4 -DSIGRET=void -I/usr/local/include/tk8.0 \ -I/usr/local/include/tcl8.0 -I/usr/X11R6/include -I./jpeg -I./p64 -I. \ -o vic inet.o cellb_tables.o tkStripchart.o md5c.o random.o main.o net.o \ net-ip.o source.o iohandler.o timer.o idlecallback.o media-timer.o \ session.o session-rtpv1.o session-nv.o session-ivs.o decoder.o \ decoder-jpeg.o decoder-nv.o decoder-h261.o decoder-h261v1.o \ decoder-cellb.o device.o grabber.o vw.o Tcl.o Tcl2.o module.o \ transmitter.o encoder-nv.o encoder-cellb.o encoder-h261.o \ transcoder-jpeg.o framer-jpeg.o group-ipc.o confbus.o renderer.o \ renderer-window.o color.o color-true.o color-pseudo.o color-dither.o \ color-ed.o color-quant.o color-hi.o color-gray.o color-mono.o \ color-hist.o rgb-converter.o jpeg/jpeg.o p64/p64.o dct.o compositor.o \ rate-variable.o crypt.o crypt-dull.o grabber-still.o cm0.o cm1.o \ huffcode.o version.o bv.o ui-ctrlmenu.o ui-main.o ui-resource.o \ ui-srclist.o ui-stats.o ui-util.o ui-windows.o ui-switcher.o ui-extout.o \ ui-grabber.o ui-unix.o cf-main.o cf-tm.o cf-confbus.o cf-network.o \ cf-util.o tkerror.o entry.o tk.o strtol.o strtoul.o grabber-x11.cc \ grabber-meteor.o -L/usr/local/lib -ltk80 -L/usr/local/lib -ltcl80 \ -L/usr/X11R6/lib -lXext -lX11 -lm grabber-x11.cc: In method `X11Device::X11Device(const char *)': grabber-x11.cc:194: warning: the address of `free(void *)', will always be `true' grabber-x11.cc: In method `int X11Grabber::X11Grab_Initialize(Window, int, int)': grabber-x11.cc:572: warning: assuming on `X11Grabber::X11Grab_LSBWhite1()' grabber-x11.cc:572: warning: assuming on `X11Grabber::X11Grab_MSBWhite1()' grabber-x11.cc:574: warning: assuming on `X11Grabber::X11Grab_LSBBlack1()' grabber-x11.cc:574: warning: assuming on `X11Grabber::X11Grab_MSBBlack1()' grabber-x11.cc:585: warning: assuming on `X11Grabber::X11Grab_Pseudo8()' grabber-x11.cc:595: warning: assuming on `X11Grabber::X11Grab_RGB16()' grabber-x11.cc:609: warning: assuming on `X11Grabber::X11Grab_TrueXBGR24()' grabber-x11.cc:627: warning: implicit declaration of function `int VidUtil_DestroyXImage(...)' grabber-x11.cc: In method `X11Grabber::X11Grabber(const char *, const char *)': grabber-x11.cc:1014: warning: assignment to `int8 *' from `uint8 *' changes signedness grabber-x11.cc:1015: warning: assignment to `int8 *' from `uint8 *' changes signedness grabber-x11.cc: In method `int X11Grabber::capture()': grabber-x11.cc:1188: warning: implicit declaration of function `int XShmGetImage(...)' grabber-x11.cc:1194: must use .* or -* to call pointer-to-member function in `X11Grabber::c_grab (...)' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-multimedia" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
Narvi wrote: So why not instead: I think that is needlessly complicated. It's a direct extension to the present tty naming scheme. That's what he said: it's needlessly complicated. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "You intend to eat me, then?" he asked the dragon. "Well, I must admit, more for the amusement than the taste." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
On Sunday, 15 August 1999 at 12:27:57 +0200, Poul-Henning Kamp wrote: Well, autumn and winter is on us pretty soon. At least on my lattitude that means hot tea inside warm and cosy houses while the elements do their best to make life misserable for anything still left on the outside. Here are some tasks which could put an evening or more to productive and educational use for interested kernel hackers. They may also make a nice assignment for CS classes. 1. [easy] The SLIP device/interface could use the same makeover as tun, bpf and pty has received. (see also #5) Care to explain (read: document) the makeover? That would make this and the following tasks even simpler. 7. [medium] The current naming for ptys doesn't scale that well. Changing it to ttyp%d / pty%d would probably be a good idea in the long run, but the ramifications are relatively widespread (think: "ports") Is there any reason not to have both names, at least for the first 256 devices? Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel hacker tasks seek interested hackers
On Sun, 15 Aug 1999 12:27:57 +0200, Poul-Henning Kamp [EMAIL PROTECTED] said: Here are some tasks which could put an evening or more to productive and educational use for interested kernel hackers. But by all means, if you start on one of these, TELL someone about it, eh? -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message [EMAIL PROTECTED], Greg Lehey writes: On Sunday, 15 August 1999 at 12:27:57 +0200, Poul-Henning Kamp wrote: Well, autumn and winter is on us pretty soon. At least on my lattitude that means hot tea inside warm and cosy houses while the elements do their best to make life misserable for anything still left on the outside. Here are some tasks which could put an evening or more to productive and educational use for interested kernel hackers. They may also make a nice assignment for CS classes. 1. [easy] The SLIP device/interface could use the same makeover as tun, bpf and pty has received. (see also #5) Care to explain (read: document) the makeover? That would make this and the following tasks even simpler. Please examine the most recent commit to tun, bpf or pty. That is much easier than me explaining it. 7. [medium] The current naming for ptys doesn't scale that well. Changing it to ttyp%d / pty%d would probably be a good idea in the long run, but the ramifications are relatively widespread (think: "ports") Is there any reason not to have both names, at least for the first 256 devices? Size of /dev directory maybe ? I dunno, who ever implements this can do it however they like... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message [EMAIL PROTECTED] Narvi writes: : It's more the argument of "why do it *significantly* differently from : others?" VMS has done the PTYx: since the mid 80's :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : I suppose, but wouldn't the proper place be under machdep? I agree that : a linux top-level MIB would be easiest to remember. Linux isn't machdep. It is MI since we could have Linux/Alpha or Linux/MIPS emulators... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
On Sun, 15 Aug 1999, Warner Losh wrote: In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : I suppose, but wouldn't the proper place be under machdep? I agree that : a linux top-level MIB would be easiest to remember. Linux isn't machdep. It is MI since we could have Linux/Alpha or Linux/MIPS emulators... Well then, we need to move it a directory level and take out machine dependencies, and make it machine independent. Warner Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
Amancio Hasty wrote: Any one care to recommend a CD writer for FreeBSD-current since thats typically what I run over here. Well, im using a Sony 948S here, works fine under -CURRENT with GCOMBUST (as a front end to mkisofs, mkhybridfs and cdrecord).. except that GCOMBUST occasionally cant figure out the target, rerunning it seems to get past this minor problem. mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
On Sun, 15 Aug 1999, Amancio Hasty wrote: Any one care to recommend a CD writer for FreeBSD-current since thats typically what I run over here. Are you asking for recommendation about hardware or software? It's not evident from your wording. Tnks -- Amancio Hasty [EMAIL PROTECTED] Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
