Back to Home / #uml / 2008 / 12 / Prev Day | Next Day
#uml IRC Logs for 2008-12-11

---Logopened Thu Dec 11 00:00:16 2008
00:37-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
02:19-!-hfb [] has joined #uml
02:45-!-Basic [] has quit [Ping timeout: 480 seconds]
03:06-!-Basic [] has joined #uml
03:49-!-balbir_ [~balbir@] has joined #uml
04:00-!-kos_tom [] has quit [Remote host closed the connection]
04:05-!-kos_tom [] has joined #uml
06:24-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
09:49-!-tchan [] has quit [Quit: WeeChat 0.2.7-dev]
09:50-!-tchan [] has joined #uml
10:34-!-hfb [] has quit [Quit: Leaving]
11:32-!-Basic [] has quit [Ping timeout: 480 seconds]
11:35-!-hfb [] has joined #uml
11:47-!-jdike [] has joined #uml
11:47<jdike:#uml>Hi guys
11:51<nDuff:#uml>Should I be using a pty for large-scale 8-bit-clean data transfer between host and guest rather than the ssl driver?
12:10<jdike:#uml>doesn't matter
12:34-!-balbir_ [~balbir@] has joined #uml
12:36<nDuff:#uml>hmm; the ssl driver doesn't seem to be clean -- at one point I lost a byte (after several MB of transfer), and in other cases I'm getting occasional odd errors.
12:36<jdike:#uml>they should be basically the same
12:36<rob0:#uml>Multiply those by two, and make them even errors!
12:37<nDuff:#uml>rob0, :)
12:37<nDuff:#uml>("odd errors" ~= connection hanging for no apparent reason)
12:39<nDuff:#uml>...seems fine when I'm not pushing too much data; I'm not sure if this would be related to full-buffer corner cases, or simply multiplying a constant error rate over larger transfer amounts.
13:16-!-Basic [] has joined #uml
13:32-!-BasicOSX [] has joined #uml
13:38-!-Basic [] has quit [Ping timeout: 480 seconds]
14:12-!-balbir_ [~balbir@] has quit [Quit: Ex-Chat]
14:13-!-balbir_ [~balbir@] has joined #uml
14:23-!-kos_tom_ [] has joined #uml
14:27-!-kos_tom [] has quit [Ping timeout: 480 seconds]
14:41-!-aindilis [~aindilis@] has quit [Remote host closed the connection]
16:39-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
16:40<stmartin:#uml>nDuff: a real serial line is not reliable either. What are you using on top of it?
16:41<nDuff:#uml>stmartin, the line protocol used by CCGFS, a FUSE filesystem.
16:42<stmartin:#uml>what if you try running something like PPP over it?
16:42<nDuff:#uml>...well, that on one serial line; I'm running the NBD protocol over the other.
16:43<nDuff:#uml>Good question; haven't tried it. I'd expect that PPP's error correction would do some good, but it's also complexity I'd like to avoid.
16:44<nDuff:#uml>Granted, a real-life serial line isn't reliable either; that's why I was asking if switching to virtual PTYs would be better.
16:44<stmartin:#uml>I suspect that what you want is something more akin to a Unix pipe.
16:44<nDuff:#uml>stmartin, indeed so, but I don't know of a good way to do that between host and guest (particularly without setting up networking).
16:44<stmartin:#uml>According to Jeff's book the two drivers are basically the same codebase, so its unlikely.
16:45<jdike:#uml>they are
16:46<jdike:#uml>I don't see any reason they'd behave differently
16:46<stmartin:#uml>jdike: do the virtual serial lines implement hardware flow control? If so, how?
16:47<jdike:#uml>I don't believe so
16:47<jdike:#uml>depends on what hardware flow control is
16:48<stmartin:#uml>hardware flow control = RTS/CTS lines (in the physical realm at least)
16:48<jdike:#uml>they won't do anything to signal the other end to stop sending data
16:48<jdike:#uml>yeah, and I don't know what that corresponds to with pts
16:49<stmartin:#uml>nDuff: there you have it, just as a real-life equivalent any reliability and flow control must be done from a higher layer.
16:50<stmartin:#uml>jdike: in the absence of serial hardware I suspect it would map to two added boolean values to model the status of RTS/CTS.... that could get a bit more complicated if you want to model particular types of crossover cables.
16:51<jdike:#uml>but how does that work across a pty?
16:51<stmartin:#uml>so possibly four boolean values (RTS and CTS for each side), plus perhaps other pins, plus some sort of pinning configuration.
16:51<jdike:#uml>are there ioctls to simulate signals across those lines
16:53<stmartin:#uml>Hmm, while ioctl can impact some of this, perhaps it would be better to create a different driver that models a serial link, perhaps in a similar manner to uml_switch.
16:54<stmartin:#uml>then behaviours could also be added, such as simulating a particular bit error rate (BER), 8-bit clean operation, synchronous/asynchronous (and in the case of synchronous which end is modelled as the master)
16:54<stmartin:#uml>this would be really useful for educational purposes and for use in things such as Vyatta (open source routing platform)
16:56*stmartin:#uml teaching networking using UML
16:56<stmartin:#uml>in a similar vein an optical link might also be modelled.
16:58*nDuff:#uml switches from serial lines over to the TTY driver and tries to reproduce his issue, just on the off chance that the assumptions by the rest of the system related to flow control are more conducive.
16:59<stmartin:#uml>You do realise that TTYs are just serial devices with a particular line discipline, right? By default the TTYs in a standard Linux environment are generally 38400 baud.
17:01*nDuff:#uml wasn't aware of that, no. (should have been, I suppose, since I was aware that TERMIOS applied).
17:02<nDuff:#uml>...anyhow, not requiring the user to have CONFIG_SSL enabled is a benefit in and of itself.
17:03<stmartin:#uml>Why? Its in by default, just like the console driver. No?
17:03<nDuff:#uml>IIRC, the config help suggests turning it off unless the user knows that [s]he needs it.
17:05<stmartin:#uml>I see... so you would prefer to have the user use something that wasn't meant to do what you want it to do?
17:05<nDuff:#uml>stmartin, ...that's the case with either of the two transports, no?
17:06<stmartin:#uml>what are you wanting to do anyway? You say you're using NBD, but that PPP is too complex, yet you need an IP interface for NBD, no?
17:06<stmartin:#uml>true enough
17:07<nDuff:#uml>I'm using NBD over a serial line to avoid the need to either configure host networking or rely on the hack that is slirp; the only networking needed is entirely internal to the guest (serial line <-> socat <-> NBD port on <-> nbd-client)
17:09*nDuff:#uml is essentially providing mountlo's functionality, albeit with NBD support (used to attach to qemu-nbd support and thus read qcow2 images) and LVM awareness within the guest.
17:11<stmartin:#uml>As I understand it qemu's switch is taken from uml_switch, so should be compatible. Might it not be easier to connect the two using the daemon network driver?
17:12<nDuff:#uml>stmartin, in this configuration I don't need to launch any actual qemu guest, just use the standalone qemu-nbd server; that said, a configuration involving such a guest certainly should be feasible (and needn't involve UML, for that matter).
17:13<nDuff:#uml>(qemu-nbd supports UNIX sockets, so I can pull this off without needing to even allocate a TCP port by connecting file descriptors opened to those sockets to the UML guest on invocation).
17:14<nDuff:#uml>s/(pull this off)/\1 in the present configuration/
17:15<stmartin:#uml>what is socat ?
17:15<nDuff:#uml>the author describes it as netcat on steroids;
17:17<nDuff:#uml>...useful for doing things like attaching named file descriptors to a UNIX socket and then exec'ing another program, or (within the guest) connecting the serial line, configured with given parameters [raw,b19200,cs8 in my case] to a TCP port.
17:18<nDuff:#uml>s/a TCP port/the ccgfs-storage daemon/
17:19<nDuff:#uml>(in this latter case I have it sticking around and passing traffic rather than simply exec'ing ccgfs-storage, such that it can watch for a complete lack of traffic on the line and shut the guest down if a timeout is exceeded).
18:27-!-jdike [] has quit [Quit: Leaving]
19:13-!-BasicOSX [] has quit [Quit: BasicOSX]
19:17-!-Basic [] has joined #uml
19:52-!-aindilis [~aindilis@] has joined #uml
20:07-!-ChrisTheGrantOBE [] has joined #uml
20:08-!-ChrisTheGrantOBE is now known as ChristheBatman
20:09<ChristheBatman:#uml>I was wondering if anyone could help me. I have been given an assignement which says using the UML class diagram, draw a normalised EER Diagram.
20:10<ChristheBatman:#uml>i was under the assumption that UML Class diagrams were for programming classes, and had nothing to do with databases
20:10<stmartin:#uml>This is the channel for User-Mode Linux, not the UML diagramming thing. Sorry for any confusion. You might try #uml on freenode
20:10<ChristheBatman:#uml>ohhhh ok sorry guys
20:11<stmartin:#uml>no prob
20:12-!-ChristheBatman [] has left #uml []
20:29-!-hfb [] has quit [Quit: Leaving]
20:35-!-Basic [] has quit [Quit: Basic]
22:55-!-balbir_ [~balbir@] has joined #uml
23:29-!-Basic [] has joined #uml
23:59-!-VS_ChanLog [] has left #uml [Rotating Logs]
23:59-!-VS_ChanLog [] has joined #uml
---Logclosed Fri Dec 12 00:00:18 2008