<Drup>
(basically, do like stack, put the keys in optional arguments that you create like currently by defualt)
<Drup>
hannes: you won't be able to do that after yomimono's changes
<hannes>
I can adapt to other mechanisms... having to provide them all the time on command-line is a bit tedious, though...
<hannes>
(but I don't want to annoy yomimono)
<yomimono>
specifying the whole thing is less annoying than partial specification and having to do unification
<Drup>
unification ?
<yomimono>
I specified a network and gateway in my config.ml , I didn't specify an ip, and I didn't specify one on the command line so I get the default one
<yomimono>
but that ip isn't on the network I asked for
<yomimono>
so that's at best a loud and immediate runtime failure, and at worst a nothing-works-and-i-don't-know-why
<Drup>
but you have to check for that at launch anyway, no ?
<yomimono>
yes, at best a loud and immediate runtime failure
<hannes>
yomimono: I agree that partial specification does not make any sense.
<hannes>
maybe the constructor (+commandline) should only support IP/netmask[:gw] (I like that gw is an option!))
<Drup>
yomimono: do you want to also forbid full specifications inside config.ml ?
<Drup>
(note: partial specifications is perfectly possible on the CLI ... :p)
<yomimono>
I'm remembering now that I think mirage-www does this as well, which is two, which is probably enough to demonstrate that it's useful
<yomimono>
drup: yes, that's why I put a loud and immediate runtime failure in there :P
<yomimono>
drup: I contemplated writing a parser for the whole config at once but that's rather painful
<yomimono>
drup: given infinite time and patience that's what I'd do, and I'd make the user specify all of it at the same time
<hannes>
yomimono: I'd be in favour of a single argument containing the entire config. makes much more sense.
<Drup>
is the format that complicated ?
<Drup>
it looks like a cute little out of context gramar :p
<yomimono>
no but the bikeshedding-to-feature ratio is going to be high and I don't like dealing with that stuff
<Drup>
ah, fair enough
<yomimono>
go nuts, I give you my blessing
<Drup>
yomimono: my attitutde towards network programming is very similar to your attitude towards compiler programming :D
<yomimono>
drup: it's great and I'm glad someone is doing it? ;)
<Drup>
exactly :D
<yomimono>
drup: and I'm also glad that person isn't me :P
<mort___1>
yomimono drup: idly wondering how this might relate to andrew's request of last night re insertion of /etc/network/interfaces
<mort___1>
though i guess that shoudl either be a full spec or no spec as well
<mort___1>
meanwhile— can anyone explain (or point me to explanation of) how all that ppf magic fmt stuff works please?
<mort___1>
i want to create a printer that works with the logging be prepends some information to every line
<yomimono>
mort___1: is there even a good spec for that? I strongly suspect that claiming to support this format will be followed by "well debian accepts this but fedora doesn't" or some similar such
<yomimono>
"so you should accept the union of all possible things"
<yomimono>
...maybe I'm too grumpy for this atm
<mort___1>
for /etc/network/interfaces? i don't know of a good spec, but on the things i've looked at it's always looked pretty similar across distros
<mort___1>
i'll admit to not having a rigorous sample though
<yomimono>
(but I thought the questions you asked about it were the right ones)
<mort___1>
ta :)
<yomimono>
mort___1: you want to make a log reporter that always prepends "this log came from mort!!!" or some such?
<mort___1>
yes
<mort___1>
specifically "this log came from tcp connection [ipaddr]:portno"
<mort___1>
or words to that effect
<yomimono>
hannes: don't you do this in tls?
<Drup>
yomimono: there is no rfc for the format ip/mask:gw ? :D
<Drup>
I can't believe that
<mort___1>
drup: i don't believe so
<mort___1>
the gateway bit is a local host configuration thing
<mort___1>
ip/mask is pretty standard
<mort___1>
(and if one were to support partial configs, i would expect to be able to set ip/mask without setting gw)
<yomimono>
having no gateway is a valid config
<yomimono>
so I'd sure hope so :D
<hannes>
having no gw is a useful configuration as well
<hannes>
mort___1: you can have a reporter which prepends <foo>, but it is unlikely what you want
<hannes>
mort___1: I have thought about this as well, and I'd think the Tag mechanism is the way to go... but I've no clue how to pass the tag(s) upwards the stack (from TCP to TLS etc.)
<Drup>
(though, you could potentially make all the arguemnts non-optional)
<yomimono>
hannes: that seems reasonable
<yomimono>
(but default gateway that isn't on the network should be a runtime error, probably)
<yomimono>
(as I'm sure you don't need me telling you :P)
<hannes>
mato: does the mirage-tracing stuff (which uses some shared memory between host and unikernel) work by any chance with solo5? (or any plans to make it work?)
<mato>
hannes: no it doesn't. in fact, i'm not sure what happens if you try a enable it -- you'll probably get a build failure
<mato>
hannes: as for making it work, the problem is there isn't really any standardised mechanism for host/guest shared memory in virtio hypervisor land
<hannes>
mato: not clear whether it is helpful to have...
<mato>
hannes: so for now, not likely to happen
<hannes>
ok
<yomimono>
the mirage frontend tool thinks that it should try to do xen stuff for any unikernel, which pretty wrong
<yomimono>
it should probably fail more gracefully for -t virtio or -t ukvm
<mato>
yeah, it should just error out with "not supported (yet)"
<yomimono>
I should probably also move away from this computer
* mato
too
<yomimono>
drup: maybe a keyed config and a config that just takes a full ipv4_config object (and same for ipv6)
<mort___1>
i am moving away from this computer
<mort___1>
byeee!
mort___1 has quit [Quit: Leaving.]
<yomimono>
an inspiration to us all!
<Drup>
yomimono: you can use the keyed config to make the other
gjaldon has quit []
<yomimono>
drup: meeting finally over, actually looking at what we're talking about now
<yomimono>
drup: as in, just call keyed config with the values passed in the ipv4_config or something more clever?
<yomimono>
(sorry to ask so many questions but I have a special talent for misunderstanding what you propose, I think :P)
<Drup>
yomimono: yes
<Drup>
(with the trick explained above)
<Drup>
yomimono: nah, I just explain badly this kind of thing
<yomimono>
drup: software and words are hard :( technical writers are wizards.
aggelos_ has quit [Ping timeout: 256 seconds]
smondet has joined #mirage
<yomimono>
drup: it seems to me that trick has the property that calling with ~address in config.ml will override a command-line setting; is that correct?
<yomimono>
(it's not necessarily a problem if so, but I'm not sure I'm right)
AltGr has left #mirage [#mirage]
fgimenez has quit []
agarwal1975 has quit [Quit: agarwal1975]
agarwal1975 has joined #mirage
aggelos_ has joined #mirage
noddy has joined #mirage
<Drup>
yomimono: depends how you call it
<Drup>
if you do ~address:(Key.pure ..) then there is no command line argument at all
noddy has quit [Ping timeout: 245 seconds]
<Drup>
if you do ~address:(Key.value my_ip_key), then it uses the predefined key
<yomimono>
...so I'm about to push a new commit and you can tell me whether it's dumb or not, maybe
<yomimono>
yeah, I figured that out, but I couldnt' figure out how to do what you meant :(
<Drup>
ok, let's first try to decide which feature we want
<yomimono>
it's not clear to me at all how to make something like is happening in kv_ro happen here, because we care about a value embedded in there
<yomimono>
we're not just matching on some key and using it to affect control flow
noddy has joined #mirage
<Drup>
ah, I see
<Drup>
give me a sec, writing a patch to show you
<Drup>
oh, you can't turn a key abstract
<Drup>
ok, that really sucks, I should change that
<Drup>
turn a value*
<yomimono>
I had assumed that was an intentional design decision for some reason :P
<Drup>
It was a design decision of "I had no idea how people would use keys and values" :D
<yomimono>
man, can't believe this has only been merged for <1 year
<yomimono>
I don't even remember how we did anything before functoria
<Drup>
this remarks makes me very happy <3
<yomimono>
:D
noddy has quit [Ping timeout: 260 seconds]
<Drup>
Actually, now I'm wondering if we could get rid of the distinction between keys and values
<yomimono>
I have nothing useful to offer on this subject, sorry!
<yomimono>
(but if you're wondering that I guess the answer is yes?)
<Drup>
ok, there were actually reasons
<Drup>
grmbl
<Drup>
(damn CPS)
agarwal1975_ has joined #mirage
<yomimono>
in light of all that, maybe the commit I just pushed is ok? ^_^;
<Drup>
sorry, I got carried away x)
<yomimono>
no problem! :D
<yomimono>
(I was feeling pretty dense for not being able to figure out what you were suggesting; I feel better now :P)
agarwal1975 has quit [Quit: agarwal1975]
agarwal1975_ is now known as agarwal1975
<Drup>
so yeah, CPS gets in the way
<Drup>
this is very unsatisfying
<Drup>
yomimono: in the end, aren't you better getting back to the previous API, with optional ipv4_config (and fall back to default), which avoid having twice the same function ?
<Drup>
(and yes, what you did is the best we can have right now)
<yomimono>
I'm looking at the previous API, but I don't think this portion of it was widely used at all
<yomimono>
most people are asking for direct_stackv4_with_static_config or generic_stackv4
<yomimono>
if you mean restoring direct_stackv4_with_static_config, yeah maybe
<Drup>
I mean merging create_ipv4 and keyed_ipv4
<Drup>
because, well, both are keyed, really
<Drup>
just one with custom defaults, and the other with "default default" ..