[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] mirage-logs and functoria



On 12 January 2016 at 14:59, Drup <drupyog+caml@xxxxxxxx> wrote:
> Le 12/01/2016 15:34, Thomas Leonard a écrit :
>>
>> On 12 January 2016 at 14:00, Drup <drupyog+caml@xxxxxxxx> wrote:
>>>>
>>>> Ideally, I'd like to integrate this with functoria. What would be the
>>>> best way to do this?
>>>> Is it possible to do something like this?
>>>>
>>>>     register "console" [mirage_logs (main $ default_console)]
>>>
>>>
>>> Not directly like that. I see several possibilities.
>>>
>>> - Make "Main" take an extra module argument
>>>        module L = struct let log = create () |> run end
>>>    then config.ml is now
>>>        let log = default_log $ default_console in
>>>        register "foo" [main $ .. $ log]
>>>
>>>    This way, the functor application of Mirage_logs.Make is outside (in
>>> the
>>> "default_log" combinator).
>>>    Maybe it could be combined with Logs.Src.create if that's desirable.
>>>
>>> - Change a bit the API, so that you have a `start` function that returns
>>> a
>>> thread that starts the logger
>>>    (which means no automated function wrapping).
>>>
>>>    Then, we declare main differently:
>>>         let main = foreign ~deps:[hidden default_log] "Unikernel.Main" (
>>> ...
>>> @-> job)
>>>    `Main.start` will receive an additional value (at least unit, but you
>>> can
>>> put whatever you want).
>>>    and that ensures that logs are initialized before the main job is
>>> executed.
>>>    This is what is done for nocrypto.
>>
>> Do you mean "before the main job's start function is called" or
>> "before any of the inputs are evaluated"? The second would be OK. The
>> docs say:
>>
>>      {- If [deps] is set, the given list of {{!abstract_impl}abstract}
>>         implementations is added as data-dependencies: they will be
>>         initialized before calling [name.connect]. }
>>
>> However, there is no [name.connect] function. If it means [name.start]
>> then I don't see what the difference is between this and declaring it
>> as a regular argument.
>
> It's the first, there are no orders between dependencies of a device.
>
> The difference is whether you also have a functor argument or not.
>
> "start" is called by connect for module declared with "foreign". This is
> because devices and foreigns were different, which is not the case any more.
> I would gladly change it for consistency, but that would break everything.
> :)
>
>>>    Function wrapping could probably be arranged by using the value passed
>>> around.
>>>    In the end, this could be like 1), but without the functor argument.
>>>
>>> - The problem with those two methods is similar to your tracing issue. It
>>> doesn't log things started before the main job.
>>>    The third possibility is, we solve
>>> https://github.com/mirage/functoria/issues/45 and we add a way to put the
>>> logger (and the tracer) there.
>>>    Again, no automated wrapping
>>
>> Yes. I think we have a slight advantage here: libraries using Logs
>> will be written to assume that there will be no log output until their
>> connect function is called (whereas libraries aren't generally aware
>> that they might be being traced). However, being able to trace the
>> connect calls is really useful, so waiting until Main.start is too
>> late.
>
>
> This would mean that, for example, network initialization is not logged.
> That limits its utility as a debugging tool.

Yes, we really need to get log output before `start` is called.
Ideally, we'd configure logging by default and require explicit user
action to disable it I think. Perhaps we could have an extra argument:
`register ~logging`. But I'm not sure how to implement it. Any ideas?
I'm currently converting tcpip to use Logs, and so far this just means
you don't see any log output during connect now.


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.