Re: nvi for serious hacking
At 1:25 PM -0600 10/17/05, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Gary Kline [EMAIL PROTECTED] writes: :vi was the first screen/cursor-based editor in computer :history. Are you sure about this? I was using screen oriented editors over a 1200 baud dialup line in 1977 on a PDP-11 running RSTS/E on a Behive BH-100. Seems like one year from vi to being deployed at Berkeley to a completely different video editor being deployed on a completely different os in the schools that I used this in seems fast. So I did some digging. vi started in about 1976[1] as a project that grew out of the frustration taht a 200 line Pascal program was too big for the system to handle. These are based on recollections of Bill Joy in 1984. It appears that starting in 1972 Carl Mikkelson added screen editing features to TECO[2]. In 1974 Richard Stallman added macros to TECO. I don't know if Carl's work was the first, but it pre-dates the vi efforts. Other editors may have influanced Carl. Who knows. I arrived in RPI in 1975. In December of 1975, we were just trying out a mainframe timesharing system called Michigan Terminal System, or MTS, from the university of Michigan. The editor was called 'edit', and was a Command Language Subsystem (CLS) in MTS. That meant it had a command language of it's one. One of the sub-commands in edit was 'visual', for visual mode. It only worked on IBM 3270-style terminals, but it was screen-based and cursor-based. The editor would put a bunch of fields up on the screen, some of which you could modify and some you couldn't. The text of your file was in the fields you could type over. Once you finished with whatever changes you wanted to make on that screen, you would hit one of 15 or 20 interrupt-generating keys on the 3270 terminal (12 of which were programmable function keys, in a keypad with a layout similar to the numeric keypad on current keyboards). The 3270 terminal would then tell the mainframe which fields on the screen had been modified, and what those modifications were. The mainframe would update the file based on that info. I *THINK* the guy who wrote that was ... Bill Joy -- as a student at UofM. I can't find any confirmation of that, though. The closest I can come is the web page at http://www.jefallbright.net/node/3218 , which is an article written by Bill. In it he mentions: By 1967, MTS was up and running on the newly arrived 360/67, supporting 30 to 40 simultaneous users. ... By the time I arrived as an undergraduate at the University of Michigan in 1971, MTS and Merit were successful and stable systems. By that point, a multiprocessor system running MTS could support a hundred simultaneous interactive users, ... But he doesn't happen to mention anything about editors or visual mode. My memory of his connection to MTS's visual-mode could very well be wrong, since I didn't come along until after visual-mode already existed. I just remember his name coming up in later discussions. However, I also think there was someone named Victor who was part of the story of 3270 support in MTS. And Dave Twyver at University of British Columbia was the guy who wrote the 3270 DSR (Device Support Routine), as mentioned on the page at: http://mtswiki.westwood-tech.com/mtswiki-index.php/Dave%20Twyver In any case, I *am* sure that MTS had a visual editor in December of 1975, which puts before vi if vi started in 1976. Unfortunately, all of the documentation of MTS lived in the EBCDIC world, and pretty much disappeared when MTS did (in the late 1990's). In my case, the first visual editor that worked under Unix was DED from the Australian Distro. it only worked on a VT100, but that's was what i had :-), then came emacs, so im one of the few that doesn't know vi. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: help regarding : To recieve and tranmit packet th' an interface
From: rashmi ns [EMAIL PROTECTED] Hello List-members, we are writing a driver for HDLC-Controller We have coded upto some extent and actully we are able to transmit and recieve a char buff in loopback (from inside a driver). But we want to tranmit/Rx a real packet in (mbuf structure) and test our code .As it is a HDLC controller does'nt have std MAC ADDRRSS . How can i actually achieve a packet transmition and reception .Are there some drivers which does the same All the point-to-point interfaces don't have a MAC address. You don't need it since there is only one place to which you can write data, into the port. Well, the problems start when you want to establish X.25 connections. Then you use the X.25 address similarly to a MAC address. But since usually the X.25 connections are static, you set up your table of connections and the translation table between the target IP address and X.25 address, similar to ARP but static. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvi for serious hacking
On Mon, Oct 17, 2005 at 01:25:32PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Gary Kline [EMAIL PROTECTED] writes: : vi was the first screen/cursor-based editor in computer : history. Are you sure about this? I was using screen oriented editors over a 1200 baud dialup line in 1977 on a PDP-11 running RSTS/E on a Behive BH-100. Seems like one year from vi to being deployed at Berkeley to a completely different video editor being deployed on a completely different os in the schools that I used this in seems fast. So I did some digging. vi started in about 1976[1] as a project that grew out of the frustration taht a 200 line Pascal program was too big for the system to handle. These are based on recollections of Bill Joy in 1984. It appears that starting in 1972 Carl Mikkelson added screen editing features to TECO[2]. In 1974 Richard Stallman added macros to TECO. I don't know if Carl's work was the first, but it pre-dates the vi efforts. Other editors may have influanced Carl. Who knows. You're probably right. I didn't know the diff between a computer and a washing machine until I was past 30; found out in 1977 and haven't looked back! My first editor was ed on V6, followed by ex, followed by vi circa June, 1978. Bill used to haul around print outs of the src to vi and csh (c). I'd be hacking in FORTRAN and Bill would be working in things that we lightyears beyond me. Ideas inspire new ideas; concepts build upon one another. This integration and cross-fertilization helps all of us. OT, but that is why I see software patents as being not only selfish but self-defeating in the longer scope of things. Let me amend my prev-statement to read that vi was among the first screen/cursor-based editors gary -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Accessing USB Mass Storage Device
At about the time of 10/18/2005 9:38 PM, M. Warner Losh stated the following: In message: [EMAIL PROTECTED] Daniel Rudy [EMAIL PROTECTED] writes: : : When the umass driver is compiled into the kernel, and one inserts a USB : mass storage device, how does one access the device descriptors (serial : number) while the device is listed as a da device? I would perfer to : have the OS do all the work of accessing the hardware. The serial number can be obtained with devifo. However, since cam doesn't hook into the device tree, mapping da number to umass number can be tricky in the arbitrary case. devinfo -v | grep umass umass0 pnpinfo vendor=0x054c product=0x014d devclass=0x00 devsubclass=0x00 release=0x0110 sernum=0052450548137984 intclass=0x08 intsubclass= at port=0 interface=0 : How does one read and write data to the device using /dev/ugen? One can't. You can't have multiple drivers attach to the same hardware. They would interfere with each other unless there was some sort of time domain sharing of the device. Even that would be, ummm, challanging in the arbitrary general case (but I want to get the serial number of my disk that's mounted, why can't I do that?). Arbitrary sharing is tough to do. Since ugen is so arbitrary in what you can do with it, I don't imagine it would ever be implemented. Another option would be to do what we do with pci already, and have a small set of information that we can query the device in a non-distruptive (mostly) way and expand that to usb. The usb bus (well uhub, since it is the usb bus) would create device nodes that could be querried for standard information. We've started doing this with pccard and cardbus, so you can now get, eg, the CIS, the power states (well, that's in my mind/tree right now), etc. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Looking at the man page for devinfo(8), it also contains a reference to devinfo(3). When examining the information for devinfo(3), I have come to the conclusion that this is exactly what I was looking for. I noticed a blurb in the man page for devinfo(3) that the interface is subject to refinement? Are there any plans to alter this interface in future versions? Thank You. -- Daniel Rudy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
rc scripts: how to start a process that doesn't daemonize itself?
Hi, I have a program that I would like to control via a rc script, say /usr/local/etc/rc.d/myprog problem is this program needs to be put explicitly in background. I was playing with things like command=/usr/sbin/daemon /usr/local/bin/myprog but this obviously works only for the start case. Should I just override start() completely or is there a common way to do it? I don't think I can simply pass a somewhere... thanks marco ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc scripts: how to start a process that doesn't daemonize itself?
Marco Molteni wrote: Should I just override start() completely or is there a common way to do it? I don't think I can simply pass a somewhere... Oh, yes, you can: command_args= should do the work. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc scripts: how to start a process that doesn't daemonize itself?
In the last episode (Oct 19), Marco Molteni said: I have a program that I would like to control via a rc script, say /usr/local/etc/rc.d/myprog problem is this program needs to be put explicitly in background. I was playing with things like command=/usr/sbin/daemon /usr/local/bin/myprog but this obviously works only for the start case. Should I just override start() completely or is there a common way to do it? I don't think I can simply pass a somewhere... Try putting the in command_args; that way it'll only be used during startup. I do that in some of my homegrown rc.d scripts. A (probably cleaner) way is to set start_cmd=/usr/sbin/daemon /usr/local/bin/myprog -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to determine link of umass/da devices
In message: [EMAIL PROTECTED] Tom Alsberg [EMAIL PROTECTED] writes: : With tools like usbdevs and sysctl, I can find out what USB devices : are connected, and also what USB drivers handle them (so I can see, : for example, that there is a SanDisk Cruzer Micro connected to port 2 : in bus 3 and the umass driver under it). You can find this out best via the devinfo interface. : I can also find out what da devices there are using camcontrol. Right. cam doesn't hook the da devices into the device tree. : However, how can I find out which da device was assigned to which : umass/usb device? Generally, you can't. There's not really an interface to get this information. devinfo assumes that things like disk drives would be in the device tree and except for cam, all other drivers conform to this world view. There's some efforts to update and lock cam which I think will rectify this. : I see this info in some inconvenient form in : dmesg. But I need something easier to handle programmatically to : write a program that uses that data. I prefer not to resort to some : ugly hack like trying to parse dmesg. Especially since dmesg can disapper quickly on some systems. : Also, I'd be interested if it were possible to have my program : informed when devices are connected/disconnected. Can a process ask : usbd to send it some signal and somehow provide the details of the : event when a device is connected/disconnected? devd provides a pipe of all events from the kernel in /var/run/devd.pipe. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc scripts: how to start a process that doesn't daemonize itself?
On Wed, 19 Oct 2005 10:36:55 -0500 Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Oct 19), Marco Molteni said: I have a program that I would like to control via a rc script, say /usr/local/etc/rc.d/myprog problem is this program needs to be put explicitly in background. I was playing with things like command=/usr/sbin/daemon /usr/local/bin/myprog but this obviously works only for the start case. Should I just override start() completely or is there a common way to do it? I don't think I can simply pass a somewhere... Try putting the in command_args; that way it'll only be used during startup. I do that in some of my homegrown rc.d scripts. A (probably cleaner) way is to set start_cmd=/usr/sbin/daemon /usr/local/bin/myprog thanks to you and the others posters for the trick. It works, but as you say it smells hackish. For one, it doesn't detach from the controlling tty. Not a big deal when run from init I think, but it may make a difference when run multiuser from a terminal (say myprog forcestart). anyway, better than nothing ;-) thanks again marco -- He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. -- Thomas Jefferson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvi for serious hacking
In article [EMAIL PROTECTED] you write: Hello, FreeBSD people. First thing to mention is that I'm very experienced Emacs user. I was using it [ snip reasons for becoming a VI user ] and according to documentation it has powerful editing mechanism. It is. So, my question goes to all FreeBSD hackers who uses `nvi' as their general editor. Is it possible to do serious hacking with it? More accurate: I mostly use vim, not nvi. Reasons: - vim can do syntax highlighting. - vim does smart indentation correctly for my value of correctly. * What programming features it support? (Does it have something like etags? Does it have interface to gdb? And such other things..) Ctags originated with vi. I can't imagine why an editor should interface with gdb -- that's what other windows are for. * Is it possible to use it comfortable with Dvorak layout? (I noticed some bindings that relies on keys arrangement) I use a Dvorak keyboard all the time. It works just fine; your fingers have already learned the hard part. Besides, j and k are still next to each other, and I almost never use h or l for moving left/right (usually use space or W for right and 0 to go to beginning of line). * How to setup it to standard FreeBSD C code indentation? And don't use tabs as well. :set tabstop=8 shiftwidth=4 Use tabs. They're part of the FreeBSD standard, last I checked, but that's an area of religious discussion I try to avoid. It's hard choice for me to switch old good Emacs to something new, so please give me your opinions. I've tried emacs several times, and keep going back to vi because I don't like hitting so many modifier keys. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvi for serious hacking
On Wed, 2005-Oct-19 12:59:04 -0700, Steve Watt wrote: In article [EMAIL PROTECTED] you write: Does it have interface to gdb? And such other things..) ... I can't imagine why an editor should interface with gdb -- that's what other windows are for. When stepping through code, it's nice to have the current line and surrounding context automatically displayed (without clogging up your gdb session with an extra 10-20 lines of output for each step). It's also nice to able to scroll back through your entire debugging session. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc scripts: how to start a process that doesn't daemonize itself?
On Wed, 19 Oct 2005, Marco Molteni wrote: Try putting the in command_args; that way it'll only be used during startup. I do that in some of my homegrown rc.d scripts. A (probably cleaner) way is to set start_cmd=/usr/sbin/daemon /usr/local/bin/myprog thanks to you and the others posters for the trick. It works, but as you say it smells hackish. For one, it doesn't detach from the controlling tty. Not a big deal when run from init I think, but it may make a difference when run multiuser from a terminal (say myprog forcestart). anyway, better than nothing ;-) The daemon(8) page claims it detaches from the tty. You may also want to use the -f argument to redirect stdio. If it isn't working properly, please file a PR, thanks! Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adding new device to base system
On Wed, 19 Oct 2005 00:20, Jerry wrote: I reinstalled FreeBSD 5.4. It works now. I may have broken something earlier. A reinstall is a bit agressive.. You could have just re-cvsup'd your source tree. -Original Message- From: Daniel O'Connor [mailto:[EMAIL PROTECTED] Sent: Monday, October 17, 2005 6:09 PM To: freebsd-hackers@freebsd.org Cc: [EMAIL PROTECTED] Subject: Re: adding new device to base system On Tue, 18 Oct 2005 02:22, [EMAIL PROTECTED] wrote: /usr/src/sys/i386/conf/TARTAR ../../conf/files: FreeBSD: must be count, optional, mandatory or standard *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Looks like you broke sys/conf/files somehow. Do a cvs diff on it and post it here. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpVFJ045Jqjt.pgp Description: PGP signature
Which branch?
Hello, My computer is running with FreeBSD 5.4-STABLE. I've tried updating the source tree with RELENG_5, but I get some compile time errors. Is the RELENG_5 branch abandoned? Also, I must download the RELENG_6 branch (6-STABLE) and contribute to this branch?. Thanks... Regards -- . 0 . | Daniel Molina Wegener . . 0 | dmw at unete dot cl 0 0 0 | FreeBSD Power User ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Which branch?
On Thu, Oct 20, 2005 at 01:09:02AM -0300, Daniel Molina Wegener wrote: Hello, My computer is running with FreeBSD 5.4-STABLE. I've tried updating the source tree with RELENG_5, but I get some compile time errors. Is the RELENG_5 branch abandoned? No. We can't help you with your errors though unless you tell use what they are. Also, I must download the RELENG_6 branch (6-STABLE) and contribute to this branch?. You don't have to, but you might want to. It's got improvements and is clearly the way forward. -- Brooks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
export nullfs via NFS
Hi, All! I want to export folder with very long pathname via NFS. This is inconvenient. I try to mount this folder into other folder with shorter pathname through nullfs. But nullfs can not be exported via NFS. I have made the small patch for mountd and nullfs that allow export nullfs. But i have one problem :) When i mount the remote file system, i can't work with it, i get the input/output error. What i can do for export nullfs via NFS? Patch can be found here: http://butcher.heavennet.ru/nullfs_export/ -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
USB mouse problem
I've had a Gyration USB keyboard/mouse combo for a few years, and haven't used
the mouse, simply because it didn't work with FreeBSD. I've finally gotten
around to trying to do something about that.
Both the mouse and keyboard are recognized. The problem is that all input is
ignored unless the middle mouse button is depressed. In that case, though, the
input is garbled... There are spurious button events and the x/y/z axes
seemingly random values. y/z tend to stay around the same number, though those
numbers change each time that ums is attached.
I've found where the input is disguarded, in ums.c:447 (RELENG_5 tag)
ibuf = sc-sc_ibuf;
/*
* The M$ Wireless Intellimouse 2.0 sends 1 extra leading byte of
* data compared to most USB mice. This byte frequently switches
* from 0x01 (usual state) to 0x02. I assume it is to allow
* extra, non-standard, reporting (say battery-life). However
* at the same time it generates a left-click message on the button
* byte which causes spurious left-click's where there shouldn't be.
* This should sort that.
* Currently it's the only user of UMS_T so use it as an identifier.
* We probably should switch to some more official quirk.
*/
if (sc-flags UMS_T) {
if (sc-sc_iid) {
if (*ibuf++ == 0x02)
return;
}
} else {
if (sc-sc_iid) {
if (*ibuf++ != sc-sc_iid)
// Returns here
return;
}
}
It returns in the else block as labeled by the comment. The value of *ibuf
(i.e. sc-sc_ibuf[0]) is always 0x00 and sc-sc_iid is always 0x04. With the
wheel down, they're both 0x04.
If I comment out the return line, I get the same garbled data that I get with
the wheel button down. In that case, though, the x access movement values are
more or less accurate.
This seems to me like the problems caused by setting the wrong protocol for
ps/2/serial mice, but you can't choose the protocol for USB mice.
Any help on the matter would be appreciated. I have debugging output also, if
that would help.
Here's what I get on ums attach:
ums0: Gyration GyroPoint RF Technology Receiver, rev 1.10/1.20, addr 2, iclass
3
/1
ums0: 7 buttons and Z dir.
ums_attach: sc=0xc1faa000
ums_attach: X 8/8
ums_attach: Y 16/8
ums_attach: Z 24/8
ums_attach: B1 0/1
ums_attach: B2 1/1
ums_attach: B3 2/1
ums_attach: B4 3/1
ums_attach: B5 4/1
ums_attach: B6 32/1
ums_attach: B7 33/1
ums_attach: size=15, id=4
Thanks
--
Kris Maglione
If you are already in a hole, there's no use to continue
digging.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB mouse problem
I guess I shouldn't post to this list so late at night... The ++ part of *ibuf++ just hit me. Replacing if (sc-sc_iid) with if (0 ...) fixes the whole problem. I'd still like to find a way to fix this permanantly. -- Kris Maglione Whatever can go to New York, will. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
