Re: ls -G seems to depend on TERM=xterm-color
On Mon, 3 Jul 2000, John Baldwin wrote: > > On 03-Jul-00 Doug Barton wrote: > > Brian Fundakowski Feldman wrote: > >> > >> On Sun, 2 Jul 2000, Sean Lutner wrote: > >> > >> > I'm experiencing the same thing. ls --color doesn't seem to work for me > >> > unless like Doug, I set TERM=xterm-color. > >> > >> That's because the "color" escape sequences are defined for xterm-color > >> in termcap; xterm-color is defined as a superset of xterm (see the tc= > >> directive). > > > > Right... I am down with all that. I just wanted to confirm that the > > colorized ls depended on the xterm-color setting. > > > >> I have a lot of X resources defined, and here is one that > >> could help you guys: > >> > >> XTerm*termName: xterm-color > > > > Ok, that's a good solution, I was just using .bashrc. My point is not > > so much why, but that it be properly documented. Do you want to handle > > the update of the ls man page, or do you want me to PR a patch? > > Umm, honestly, this shouldn't be all that non-obvious. Do you expect > ls -G to work on a monochrome monitor? Of course not. :P The xterm > termcap is by default a monochrome terminal. sysinstall doesn't have > color in an xterm either w/ term=xterm. Well, I'm not really using xterm, I use Eterms, and I've NEVER had this problem before, so it was non-obvious to me. I know the Eterms I'm using are capable of displaying color ls output, because it does so when logged into shells. Also, I'm not sure if this is related, but if the xterms aren't capable of displaying color due to it's termcap, how come I can set the fg (text) to any color I choose, and they show up? > > > Thanks, > > > > Doug > > -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls -G seems to depend on TERM=xterm-color
On 04-Jul-00 Sean Lutner wrote: > Well, I'm not really using xterm, I use Eterms, and I've NEVER had this > problem before, so it was non-obvious to me. I know the Eterms I'm using > are capable of displaying color ls output, because it does so when logged > into shells. Also, I'm not sure if this is related, but if the xterms > aren't capable of displaying color due to it's termcap, how come I can set > the fg (text) to any color I choose, and they show up? The terminal can display text, the termcap just doesn't inform the programs how to do so. Termcap is a means of letting programs not have to know the control sequences needed for different terminals. A termcap need not have support for all the abilities of a terminal. Not all xterm's can display color, so the 'xterm' termcap doesn't include color support. As for your remote shells, check the term variable they use, it may be using ansi or somesuch instead of xterm. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls -G seems to depend on TERM=xterm-color
John Baldwin wrote: > >> XTerm*termName: xterm-color > > > > Ok, that's a good solution, I was just using .bashrc. My point is not > > so much why, but that it be properly documented. Do you want to handle > > the update of the ls man page, or do you want me to PR a patch? > > Umm, honestly, this shouldn't be all that non-obvious. Do you expect > ls -G to work on a monochrome monitor? Of course not. :P The xterm > termcap is by default a monochrome terminal. sysinstall doesn't have > color in an xterm either w/ term=xterm. This is obvious to you and me, but to a newer user it's not going to be obvious at all. There is going to be a bunch of people who write into the mailing lists wondering why they aren't seeing the colorized ls in their xterms. -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls -G seems to depend on TERM=xterm-color
On 04-Jul-00 Doug Barton wrote: > John Baldwin wrote: > >> >> XTerm*termName: xterm-color >> > >> > Ok, that's a good solution, I was just using .bashrc. My point is not >> > so much why, but that it be properly documented. Do you want to handle >> > the update of the ls man page, or do you want me to PR a patch? >> >> Umm, honestly, this shouldn't be all that non-obvious. Do you expect >> ls -G to work on a monochrome monitor? Of course not. :P The xterm >> termcap is by default a monochrome terminal. sysinstall doesn't have >> color in an xterm either w/ term=xterm. > > This is obvious to you and me, but to a newer user it's not going to be > obvious at all. There is going to be a bunch of people who write into > the mailing lists wondering why they aren't seeing the colorized ls in > their xterms. Well, then you are going to have to document this for every single color program people might want to run in an xterm. :) Seriously, educating the users on termcap will probably be a more productive way of going about this. One way of doing this might be to add a FAQ entry along the lines of "Programs such as ls(1) and sysinstall(8) don't display color in my xterm or other terminal?" -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls -G seems to depend on TERM=xterm-color
Hmm.. how about adding this XTerm*termname: xterm-color stuff to a default Xresources file in /usr/share/skel/, or to some default Xresources file in the X directory tree itself? (I haven't messed with X resources too much, guess it shows ;) This would break xterms running on monochrome monitors; tunable via a question in sysinstall? G'luck, Pencheff -- Thit sentence is not self-referential because "thit" is not a word. On Tue, Jul 04, 2000 at 01:14:33AM -0700, Doug Barton wrote: > John Baldwin wrote: > > > >> XTerm*termName: xterm-color > > > > > > Ok, that's a good solution, I was just using .bashrc. My point is not > > > so much why, but that it be properly documented. Do you want to handle > > > the update of the ls man page, or do you want me to PR a patch? > > > > Umm, honestly, this shouldn't be all that non-obvious. Do you expect > > ls -G to work on a monochrome monitor? Of course not. :P The xterm > > termcap is by default a monochrome terminal. sysinstall doesn't have > > color in an xterm either w/ term=xterm. > > This is obvious to you and me, but to a newer user it's not going to be > obvious at all. There is going to be a bunch of people who write into > the mailing lists wondering why they aren't seeing the colorized ls in > their xterms. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why isnt there a ext2fs.ko ?
On Mon, Jul 03, 2000, James Howard wrote: > On Mon, 3 Jul 2000, Maxime Henrion wrote: > > > Hi guys, > > > > I was wondering why the kernel module for ext2fs doesnt exist. I > > think this will be very useful because a lot of linux users come to > > FreeBSD and want to mount their existing linux partitions, and they have > > to recompile their kernel. This isn't a hard task, but it's a bit > > disappointing for new users. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=14217 > > But it doesn't seem to compile with FreeBSD-current anymore. Give me a > day or so and I will update it work with a newer FreeBSD. On this topic, > how would anyone feel about importing NetBSD's GPL-clean ext2fs source? If noone beats me to it, I'll look at it after I've committed the couple of things in my commit queue. Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the <[EMAIL PROTECTED]>rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: invlpg produces strange sig11 on PentiumPro box
> > Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > > > > > If we are talking about errata #34 the correct solution is to not use > > > 4MB pages. > > > > Is FreeBSD #29-safe? > > variable MTTRs are set as follows: > MSR (200): 0006 > MSR (201): 000ffc000800 > MSR (202): 0406 > MSR (203): 000fff000800 > MSR (204): 00f0 > MSR (205): 00000800 * > MSR (206): > MSR (207): > MSR (208): > MSR (209): > MSR (20a): > MSR (20b): > MSR (20c): > MSR (20d): > MSR (20e): > MSR (20f): > > One variable MTTR (marked *) has non-4MB aligned mask and errata #29 > affects this system. Can you look at the output of 'memcontrol list' and tell us who 'owns' this MTRR? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/security -> /etc/periodic/security ?
[ x-posted to -arch to fish for complaints ]
> James Howard wrote:
>
> > On Thu, 29 Jun 2000, Ben Smithurst wrote:
> >=20
> >> Try the attached. They haven't been thoroughly tested, but that's what
> >> -CURRENT is for, right? :-) I even remembered to update the manual page
> >> this time...
> >=20
> > This needs to have knobs and stuff located in /etc/defaults/periodic.conf
>
> Umm, which knobs? I added the only two options the security stuff currently
> uses, what else does it need?
>
> > Also, it would be cool if a security option were made to periodic(8).
>
> Well, "periodic security" will work as long as /etc/periodic/security
> exists, so I guess you just mean the docs need updating? I'll get to
> that if someone is actually planning on committing this stuff.
Perhaps the best option is to do with the inline security option and
just run ``periodic security'' from cron ? I can commit the changes.
If you send me some diffs, I'll commit them and then look at
introducing {daily,weekly,monthly,security}_silence flags that will
silence mails that have nothing to say.
Assuming there are no objections that is
> --=20
> Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
--
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
AverMedia TV Card owner - IR Remote Specs obtained.
Hi, I've got the specs for the AverMedia IR Remote Control. I do not have any AverMedia hardware. So, I need some of you to do some simple programming and testing. And I do mean simple. No kernel drivers needed. FXTV needs a small change. Randall or myself can help. And I'll make the required change to the Bt848 driver. I've got the specs from a linux programmer who just made his code both GPL and BSD licence for us. What a nice guy. ( "Pawel T. Jochym" <[EMAIL PROTECTED]> ) So, anyone interested in helping? Roger -- Roger Hardiman [EMAIL PROTECTED] be his sample source code under the BSD licence too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Monitoring modem for dialing
> Hello, > > I was wondering if someone could point me in the right direction on how > to monitor my modem to capture dialing. > > Basically I have an extra cordless phone around the house, and I wanted > to know if it was possible to hook it into my modem and then have an > application monitor the modem for dialing, then do something depending > on what was dialed... To give an example, I'm running xmms to listen to > music. It'd be cool if I could just pick up the cordless phone, and press > the #1 key (on the phone) to jump to the next song, or the #2 key to pause. > > I haven't a clue where to start! :) > > Is it even possible? Not if you want to receive incoming calls, no. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the taks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: invlpg produces strange sig11 on PentiumPro box
Mike Smith <[EMAIL PROTECTED]> wrote: > Can you look at the output of 'memcontrol list' and tell us who 'owns' > this MTRR? The `memcontrol list' gives: 0/1 BIOS write-back fixed-base fixed-length set-by-firmware active 1/1 BIOS write-back fixed-base fixed-length set-by-firmware active 2/1 BIOS write-back fixed-base fixed-length set-by-firmware active 3/1 BIOS write-back fixed-base fixed-length set-by-firmware active 4/1 BIOS write-back fixed-base fixed-length set-by-firmware active 5/1 BIOS write-back fixed-base fixed-length set-by-firmware active 6/1 BIOS write-back fixed-base fixed-length set-by-firmware active 7/1 BIOS write-back fixed-base fixed-length set-by-firmware active 8/4000 BIOS write-back fixed-base fixed-length set-by-firmware active 84000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active 88000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active 8c000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active 9/4000 BIOS write-back fixed-base fixed-length set-by-firmware active 94000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active 98000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active 9c000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active a/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active a4000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active a8000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active ac000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active b/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active b4000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active b8000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active bc000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c1000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c2000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c3000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c4000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c5000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c6000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c7000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c8000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active c9000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active ca000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active cb000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active cc000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active cd000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active ce000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active cf000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d1000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d2000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d3000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d4000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d5000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d6000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d7000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d8000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active d9000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active da000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active db000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active dc000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active dd000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active de000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active df000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active e/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active e1000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active e2000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active e3000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active e4000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active e5000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active e6000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active e7000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmwa
FreeBSD 4 Question : how to get pccardd on a desktop
Hello, I installed FreeBSD 4.0 on a desktop that has MELCO PCI bus card for PCMCIA cards. I am having some trouble getting pccardd work on this host. MELCO card is recognized as follows (dmesg output): pcic-pci0: irq 0 at device 15.0 on pci0 But when I use rc.pccard to invoke pccardd I get /dev/card0 not defined message and pccardd doesnot start. I used GENERIC.KAME kernel configuration file that is included in kame-2703-freebsd40-snap.tgz Thanks in advance, -- Behcet Sarikaya Computer Communications Lab. The University of Aizu Tsuruga, Ikki-machi, Aizu-wakamatsu City Fukushima, 965-8580 Japan Tel. +81-242-37-2559 Fax. +81-242-37-2742 Home page: http://www.u-aizu.ac.jp/~sarikaya/ email: [EMAIL PROTECTED]
Re: /etc/security -> /etc/periodic/security ?
James Howard wrote:
> For each script under /etc/periodic/{daily,weekly,monthly}/, there is a
> knob in /etc/defaults/periodic. This controls whether the script is run
> and maybe gives it some options. For instance, the daily/440.status-mailq
> knobs look like this:
>
> # 440.status-mailq
> daily_status_mailq_enable="YES" # Check mail status
> daily_status_mailq_shorten="NO" # Shorten output
oh, right, ok. That should be simple enough.
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
PGP signature
Re: why isnt there a ext2fs.ko ?
Statically Compiled modules are much better then the lkd's. Get used to it :P > > > > > Hi guys, > > > > > > I was wondering why the kernel module for ext2fs doesnt exist. I > > > think this will be very useful because a lot of linux users come to > > > FreeBSD and want to mount their existing linux partitions, and they >have > > > to recompile their kernel. This isn't a hard task, but it's a bit > > > disappointing for new users. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=14217 > > > > But it doesn't seem to compile with FreeBSD-current anymore. Give me a > > day or so and I will update it work with a newer FreeBSD. On this >topic, > > how would anyone feel about importing NetBSD's GPL-clean ext2fs source? > >If noone beats me to it, I'll look at it after I've committed the >couple of things in my commit queue. > > > >Adrian > >-- >Adrian Chadd Build a man a fire, and he's warm for the ><[EMAIL PROTECTED]> rest of the evening. Set a man on fire and > he's warm for the rest of his life. > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-hackers" in the body of the message Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AverMedia TV Card owner - IR Remote Specs obtained.
I'll be more than happy to help out. Just let me know what I need to do. -Will On Tue, 4 Jul 2000, Roger Hardiman wrote: > Hi, > I've got the specs for the AverMedia IR Remote Control. > > I do not have any AverMedia hardware. > So, I need some of you to do some simple programming > and testing. And I do mean simple. No kernel drivers needed. > > FXTV needs a small change. Randall or myself can help. > And I'll make the required change to the Bt848 driver. > > > I've got the specs from a linux programmer who just > made his code both GPL and BSD licence for us. > What a nice guy. ( "Pawel T. Jochym" <[EMAIL PROTECTED]> ) > > > So, anyone interested in helping? > > Roger > -- > Roger Hardiman > [EMAIL PROTECTED] > be his sample source code under the BSD licence too. > > > 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-hackers" in the body of the message
fsck
hi guys i was experementing with writing kernel modules and my kernel panic and my filesystems too. when i fsck it tells me ** /dev/ad0s2a (NO WRITE) ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2902 files, 45030 used, 4553 free (41 frags, 564 blocks, 0.1% fragmentation) and fsck -p /dev/ad0s2a: NO WRITE ACCESS /dev/ad0s2a: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. what is it? -av To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/security -> /etc/periodic/security ?
Brian Somers wrote: >> Well, "periodic security" will work as long as /etc/periodic/security >> exists, so I guess you just mean the docs need updating? I'll get to >> that if someone is actually planning on committing this stuff. > > Perhaps the best option is to do with the inline security option and > just run ``periodic security'' from cron ? I can commit the changes. I don't think there's really a problem with just running security from daily. I can add a note that this is normal practice in the manpage, and that security shouldn't be run separately unless you set daily_security_enable=NO or whatever the option is. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
profiling tools for Intel Machines
Hello, Are there any tools for FreeBSD on Intel machines for whole system profiling ? kgmon profiles only the kernel, and GPROF does not provide profiling for multiprocess applications (e.g. a multiprocess web server). Thank you, Cristian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: invlpg produces strange sig11 on PentiumPro box
> > > > If it's something that can be done as eg. a KLD > > > > we might want to do that instead, or through some other mechanism for > > > > handling these sort of CPU quirks. > > > > > > It sounds good. If binary-format quriks is supported, we can supply > > > update modules for new CPU and newly found errata like the update > > > module for AMD K6-2 CPU of Windows 95. > > > > Indeed. This won't help us where we need to modify the actual behaviour > > of a system component, but when we can perform external corrective > > actions, it will help a lot. > > I don't understand the idea here. Are you going to have a KLD that > patches the kernel? That's the general idea. > If so, you'd have to make world before it'd become > active, in which case rebuilding the kernel would be quicker. How so? Especially if it's required for the kernel to work at all, it's already built and waiting on the distribution media so that you can just load-and-go. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the taks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VPNs and FreeBSD
On Sun, 2 Jul 2000, Nick Rogness wrote: > On Sun, 2 Jul 2000, Stephen Hocking wrote: > > > Has anyone done this yet? I've just acquired this shiny new cable modem and > > would like to have secure access to my place of work (even though they're only > > 10 minutes walk away!) > > I have done just that with nos-tun and Road Runner service. I That's a Virtual Public Network, then..better not log into your work machines via telnet over that link :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI HBA device detection?
Nat Lanza wrote: > > Mike Smith <[EMAIL PROTECTED]> writes: > > > If this is meant to be an exercise in writing a CAM HBA driver, then you > > need to teach your disk-emulation code about the basic SCSI commands > > (INQUIRY, TEST UNIT READY, etc). The SCSI infrastructure will use these > > commands to automatically detect your drives. > > I already have code for handling the basic SCSI commands (I'm really > porting a scsi-ramdisk driver from Linux rather than writing from > scratch). The bit I'm curious about are which XPT actions I'll need to > support other than XPT_PATH_INQ and XPT_SCSI_IO. The tutorial in DaemonNews has this information, as well as information on minimal implementations of the reqired actions. Obviously the actions for SCSI negotiations don't need to be supported because these negotiations make no sense for an emulator or over IP. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI HBA device detection?
> > The tutorial in DaemonNews has this information, as well as information > on minimal implementations of the reqired actions. Obviously the actions > for SCSI negotiations don't need to be supported because these > negotiations make no sense for an emulator or over IP. > Or over Fibre Channel (which the DaemonNews article completely missed) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls -G seems to depend on TERM=xterm-color
John Baldwin wrote: > > On 04-Jul-00 Doug Barton wrote: > > John Baldwin wrote: > > > >> >> XTerm*termName: xterm-color > >> > > >> > Ok, that's a good solution, I was just using .bashrc. My point is not > >> > so much why, but that it be properly documented. Do you want to handle > >> > the update of the ls man page, or do you want me to PR a patch? > >> > >> Umm, honestly, this shouldn't be all that non-obvious. Do you expect > >> ls -G to work on a monochrome monitor? Of course not. :P The xterm > >> termcap is by default a monochrome terminal. sysinstall doesn't have > >> color in an xterm either w/ term=xterm. > > > > This is obvious to you and me, but to a newer user it's not going to be > > obvious at all. There is going to be a bunch of people who write into > > the mailing lists wondering why they aren't seeing the colorized ls in > > their xterms. > > Well, then you are going to have to document this for every single color > program people might want to run in an xterm. :) And the problem with that would be what, exactly? > Seriously, educating the > users on termcap will probably be a more productive way of going about this. > One way of doing this might be to add a FAQ entry along the lines of > "Programs such as ls(1) and sysinstall(8) don't display color in my xterm > or other terminal?" I agree that user education is a noble goal, and if you didn't already realize it, one that I have supported with my own efforts for a long time. However, I can see the "writing on the wall" regarding user confusion over the color ls issue. This _specific_ feature has been often requested by users on -questions, most of whom (dare I say it?) are recent linux converts. Therefore, with this _specific_ feature it will pay off more in both the long and short terms if we put the cookies down a few shelves to start with, and add an enticement for them to eat some meat and potatoes when they are ready. So, I've put my time where my mouth is and produced the attached patch for ls.1. I am 100% open to modifications of both style and content, my only request being that someone commit _something_ before 4.1 goes out the door. Since Andrey MFC'ed the color bits already (a welcome move, don't get me wrong) there is slightly more urgency to this matter then there was previously. John, when your FAQ entry is done, please feel free to add it to the SEE ALSO section of ls.1. :) Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? Index: ls.1 === RCS file: /usr/ncvs/src/bin/ls/ls.1,v retrieving revision 1.38 diff -u -r1.38 ls.1 --- ls.12000/06/22 10:07:46 1.38 +++ ls.12000/07/04 22:56:57 @@ -100,6 +100,20 @@ In addition to those mentioned above in .Fl F , some extra attributes (setuid bit set, etc.) are also displayed. +The colorization is dependent on a terminal type with the proper +.Xr termcap 5 +capabilities. +The default +.Dq cons25 +console has the proper capabilities, +however if you want to display the colors in an +.Xr xterm 1 +for example, +you need to set your +.Ev TERM +variable to +.Dq xterm-color . +Other terminal types may require similar adjustments. .It Fl H Symbolic links on the command line are followed. This option is assumed if none of the @@ -478,6 +492,10 @@ columns have changeable widths. The fields are, in order: inode, block count, number of links, user name, group name, flags, file size, file name. +.It Ev TERM +The +.Fl G +option depends on a terminal type with color capabilities. .It Ev TZ The timezone to use when displaying dates. See @@ -492,6 +510,8 @@ .Sh SEE ALSO .Xr chflags 1 , .Xr chmod 1 , +.Xr xterm 1 , +.Xr termcap 5 , .Xr symlink 7 , .Xr sticky 8 .Sh HISTORY
Re: SCSI HBA device detection?
Matthew Jacob wrote: > > > > > The tutorial in DaemonNews has this information, as well as information > > on minimal implementations of the reqired actions. Obviously the actions > > for SCSI negotiations don't need to be supported because these > > negotiations make no sense for an emulator or over IP. > > > > Or over Fibre Channel (which the DaemonNews article completely missed) Well, I concentrated on the CAM side of interface. The underlying hardware is one of device-dependent parts. BTW, I looked up the list of of absolutely neccessary calls for simulated SCSI: XPT_SCSI_IO XPT_RESET_BUS (at least silently return success) XPT_ABORT (at least return CAM_UA_ABORT) XPT_CALC_GEOMETRY XPT_PATH_INQ -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls -G seems to depend on TERM=xterm-color
On Tue, Jul 04, 2000 at 04:17:53PM -0700, Doug Barton wrote: > > So, I've put my time where my mouth is and produced the attached patch > for ls.1. I am 100% open to modifications of both style and content, my > only request being that someone commit _something_ before 4.1 goes out > the door. Since Andrey MFC'ed the color bits already (a welcome move, > don't get me wrong) there is slightly more urgency to this matter then > there was previously. John, when your FAQ entry is done, please feel > free to add it to the SEE ALSO section of ls.1. :) I agree with the bit about needing proper termcap capablities, I almost added something like this myself earlier today. It's overkill to talk about xterm in the man page though. This should be in an FAQ entry or in the hand book IMO. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why isnt there a ext2fs.ko ?
On Tue, 4 Jul 2000, Cosmic 665 wrote: > > Statically Compiled modules are much better then the lkd's. Get used to it > :P But I only need EXT2FS support once everyone few months. It makes no sense to have it eating kernel memory 100% of the time. Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: invlpg produces strange sig11 on PentiumPro box
On Tue, 4 Jul 2000, Mike Smith wrote: > > I don't understand the idea here. Are you going to have a KLD that > > patches the kernel? > > That's the general idea. > > > If so, you'd have to make world before it'd become > > active, in which case rebuilding the kernel would be quicker. > > How so? Especially if it's required for the kernel to work at all, it's > already built and waiting on the distribution media so that you can just > load-and-go. I can't think of a single situation where you wouldn't want your processor directly supported in the kernel w/o external KLDs. I'm of the impression that patching KLDs would just become ignored over time, not being properly updated as needed. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
