SLIP coexisting with serial data?
I have a situation in which it would be useful to run SLIP on a serial console. Obviously, this won't work very well at present. (The machine has only one serial port and no useful network interfaces.) I was looking at improving if_sl.c to support encapsulating normal serial data on the SLIP's tty as packets, thus merging it into the packet stream. I ran into some problems, but think I can handle them; I'm writing to ask if there's any interest from anyone else in this sort of thing, in upgrading SLIP to support normal serial output. I was thinking of making this another protocol type, akin to what I mentioned (probably on tech-net) back in '02 - I just now (finally) filed kern/43959 containing patches to support v6 as well as v4, something that's easy compared to making the tty still work as a tty, but which includes a good deal of multi-protocol scaffolding that's semi-necessary for the way I've been envisioning doing serial data. Thoughts? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: SLIP coexisting with serial data?
Dear Mouse, On Sun, Oct 10, 2010 at 04:41:40AM -0400, der Mouse wrote: I was looking at improving if_sl.c to support encapsulating normal serial data on the SLIP's tty as packets, thus merging it into the packet stream. I ran into some problems, but think I can handle them; I'm writing to ask if there's any interest from anyone else in this sort of thing, in upgrading SLIP to support normal serial output. I've encountered that on a serial protocol in my Arduino work. It worked quite well i have to say. It worked due to a packet starting with an unique byte. If the state machine is in this `start of packet mode' all other bytes are output as received serially. All terminal data sent the other way is treated the same; its buffered and when the packet is finished it is sent. Trouble with this is of course that you are limited in your bytes for the console. I don't know SLIP anymore by heart but maybe you could `invent'/use an IP# of 127.0.0.1 as a special case (or 0.0.0.0) to carry the key/terminal stuff. This would only need a small change in if_sl.h to filter out the magic destination inserting it in a tty driver that also buffers output and inserts it into the SLIP stream with the magic address. On the challenged machine the console could then be hardwired to this special tty. Cheers, Reinoud
Re: SLIP coexisting with serial data?
der Mouse mo...@rodents-montreal.org writes: I was thinking of making this another protocol type, akin to what I mentioned (probably on tech-net) back in '02 - I just now (finally) filed kern/43959 containing patches to support v6 as well as v4, something that's easy compared to making the tty still work as a tty, but which includes a good deal of multi-protocol scaffolding that's semi-necessary for the way I've been envisioning doing serial data. baiting-mode Maybe you could get IETF to standardize an extension to *PPP* :-) / pgpjt0M5JYfEG.pgp Description: PGP signature
Re: SLIP coexisting with serial data?
On Sun, Oct 10, 2010 at 04:41:40 -0400, der Mouse wrote: I have a situation in which it would be useful to run SLIP on a serial console. Obviously, this won't work very well at present. (The machine has only one serial port and no useful network interfaces.) Maybe something like SLIRP (http://en.wikipedia.org/wiki/Slirp)? Haven't used it in aeons and never tried it under NetBSD, though. -uwe
Re: SLIP coexisting with serial data?
I have a situation in which it would be useful to run SLIP on a serial console. Obviously, this won't work very well at present. (The machine has only one serial port and no useful network interfaces.) Maybe something like SLIRP (http://en.wikipedia.org/wiki/Slirp)? Haven't used it in aeons and never tried it under NetBSD, though. That is pretty close to sliplogin(8), and it deals with turning a login tty into a serial IP transport; it does nothing at all about encapsulating ordinary serial data that would otherwise be sent down the serial line into something that can be pulled out on the peer. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: SLIP coexisting with serial data?
I have a situation in which it would be useful to run SLIP on a serial console. [...] Given how rare the situation is, maybe it's best to do the encapsulation/decapsulation in user mode, and feed into SLIP via a pty. (I also suspect that the speeds are low, but I know you often run older machines.) Possibly. I've had remarkably bad luck using TIOCCONS. I'd also rather not wrap the serial data in IP packets. The speeds are as high as the machines involved support, which doesn't say all that much. Given the difficulty I've had trying to figure out how to implement this, I think I may be better off coming at it from another angle in any case. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: SLIP coexisting with serial data?
I was looking at improving if_sl.c to support encapsulating normal serial data on the SLIP's tty as packets, [...] I've encountered that on a serial protocol in my Arduino work. It worked quite well i have to say. It worked due to a packet starting with an unique byte. [...] I don't know SLIP anymore by heart but maybe you could `invent'/use an IP# of 127.0.0.1 as a special case (or 0.0.0.0) to carry the key/terminal stuff. Oh, that's not the problem. This is where the v6 patches have relevance: carrying v6 involves inventing a way to tag packets with types; I used one of them for v6, and it would be easy to use another for serial data. The difficulty is in the kernel: SLIP works by switching line disciplines, which makes it difficult to get normal output processing to happen - and what I want is for that to happen and then run the result through if_sl.c before sending it to the real hardware. In the light of morning, I'm not sure this will get me what I want even if I make it work. I need to think about it more /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: SLIP coexisting with serial data?
der Mouse mo...@rodents-montreal.org writes: I have a situation in which it would be useful to run SLIP on a serial console. [...] Given how rare the situation is, maybe it's best to do the encapsulation/decapsulation in user mode, and feed into SLIP via a pty. (I also suspect that the speeds are low, but I know you often run older machines.) Possibly. I've had remarkably bad luck using TIOCCONS. I'd also rather not wrap the serial data in IP packets. The speeds are as high as the machines involved support, which doesn't say all that much. It seems you want to have a console (in the wscons sense) which is *not* associated with a serial port, and then bind that to a logical serial channel on a SLIP instance which is instead bound to a serial port. Maybe that doesn't make sense, but it seems doable to me. pgpK8IBYF3yHw.pgp Description: PGP signature
Re: SLIP coexisting with serial data?
I wonder if you would need this kind of console even for ddb work. Well, I want it to work for direct kernel-user interaction; ddb is an example of that, but so are pre-single-user things such as userconf and printing autoconf output. If you need console for ddb, things get messy. Indeed they do. As I mentioned in another message I sent moments ago, I'm currently looking at, basically, importing SLIP into the relevant serial-port driver, so that it becomes not just a tty and console driver, but a tty, console, and network interface driver. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project results)
On Tue, Oct 5, 2010 at 3:24 PM, Lourival Vieira Neto lourival.n...@gmail.com wrote: Hi folks, I'm glad to announce the results of my GSoC project this year [1]. We've created the support for scripting the NetBSD kernel with Lua, which we called Lunatik and it is composed by a port of the Lua interpreter to the kernel, a kernel programming interface for extending subsystems and a user-space interface for loading user scripts into the kernel. You can see more details on [2]. I am currently working on the improvement of its implementation, on the documentation and on the integration between Lunatik and other subsystems, such as npf(9), to provide a real usage scenario. I'd like to take this space also to publicly thank Marc Balmer, for his kind support; prof. Roberto Ierusalimschy, for his comprehension and support; and NetBSD developers for their prompt help. [1] http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd/t127230760748 [2] http://netbsd-soc.sourceforge.net/projects/luakern/ Cheers, -- Lourival Vieira Neto I eagerly waited to see the results of this project all summer, I did peruse the code as soon as you put it up on the google code hosting site. My brief notes (from memory): I didn't see any bindings, maybe there were some, but if I missed them there can't be very many, Lua in the kernel is fairly useless unless you can call into the public kernel api. I didn't like the fact that the only option for loading a script into the kernel was to load the script source. I would make loading pre-compiled scripts the preferential method. In fact, I would probably tear eval out of the kernel lua implementation and only support loading of precompiled byte-code into the kernel. I hope you continue working on this, I see potential and at some point I would like to evaluate this for inclusion in DragonFly BSD. Best, Sam
Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project results)
On Sun, Oct 10, 2010 at 10:45 PM, Samuel Greear l...@evilcode.net wrote: (...) My brief notes (from memory): I didn't see any bindings, maybe there were some, but if I missed them there can't be very many, Lua in the kernel is fairly useless unless you can call into the public kernel api. Our proposal on this summer was to deliver a port of Lua and mechanisms for loading scripts into the kernel, not to provide bindings to the entire kernel. However, you are totally welcome to join this effort and write some bindings ;-). I didn't like the fact that the only option for loading a script into the kernel was to load the script source. I would make loading pre-compiled scripts the preferential method. In fact, I would probably tear eval out of the kernel lua implementation and only support loading of precompiled byte-code into the kernel. I'm planning to provide a kind of luac [1] to Lunatik, but it is not my main occupation now. I'm prioritizing the creation of a use case. Anyway, I would like to know what is your motivation to use pre-compiled scripts as the preferential method and why is it worrying you. I hope you continue working on this, I see potential and at some point I would like to evaluate this for inclusion in DragonFly BSD. It would be great =). [1] http://www.lua.org/manual/5.1/luac.html Cheers, -- Lourival Vieira Neto
Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project results)
On Sun, Oct 10, 2010 at 10:45 PM, Samuel Greear l...@evilcode.net wrote: On Tue, Oct 5, 2010 at 3:24 PM, Lourival Vieira Neto lourival.n...@gmail.com wrote: Hi folks, I'm glad to announce the results of my GSoC project this year [1]. We've created the support for scripting the NetBSD kernel with Lua, which we called Lunatik and it is composed by a port of the Lua interpreter to the kernel, a kernel programming interface for extending subsystems and a user-space interface for loading user scripts into the kernel. You can see more details on [2]. I am currently working on the improvement of its implementation, on the documentation and on the integration between Lunatik and other subsystems, such as npf(9), to provide a real usage scenario. I'd like to take this space also to publicly thank Marc Balmer, for his kind support; prof. Roberto Ierusalimschy, for his comprehension and support; and NetBSD developers for their prompt help. [1] http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd/t127230760748 [2] http://netbsd-soc.sourceforge.net/projects/luakern/ Cheers, -- Lourival Vieira Neto I eagerly waited to see the results of this project all summer, I did peruse the code as soon as you put it up on the google code hosting site. My brief notes (from memory): I didn't see any bindings, maybe there were some, but if I missed them there can't be very many, Lua in the kernel is fairly useless unless you can call into the public kernel api. I didn't like the fact that the only option for loading a script into the kernel was to load the script source. I would make loading pre-compiled scripts the preferential method. In fact, I would probably tear eval out of the kernel lua implementation and only support loading of precompiled byte-code into the kernel. I hope you continue working on this, I see potential and at some point I would like to evaluate this for inclusion in DragonFly BSD. Best, Sam Folks, The message above was sent both for tech-kern and Lua mailing lists and we had valuable considerations about loading pre-compiled scripts there. If want to keep track, here is the archive [http://marc.info/?t=12863140021r=1w=2]. Cheers, -- Lourival Vieira Neto
