Re: [Minios-devel] [UNIKRAFT PATCH v2 01/10] errptr.h: include errno.h

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

On 28.08.2018 14:15, Yuri Volchkov wrote:
> Hi.
>
> > The idea was that you can use this mechanism even with your own
> > defined error codes.
> What I am going to say is orthogonal to the question of including
> errno.h. I don't think own defined error codes is a nice thing. Error
> numbers really should be standardized, to avoid the nightmare of
> multiple conversions from one error system to another.
>
> The standard error codes are well established over the years they exist.
> And, I can not remember a situation when the standard errors list was
> not enough.  Even if it is the case, there is quite a bit of not used
> codes - better just extend it, if somebody wants so badly his own error
> codes.
>
> If we are talking about some third party code - I think the probability
> that it was developed for running in non-unix OS is close to 0. That
> means it either should be using definitions from the standard errno.h or
> at least it's own definitions have to be not in conflict with standard
> ones. Anyways, uk/errptr.h is in the Kernel scope. We should not mix up
> kernel and application level scopes.
I agree that errno should be good enough in most cases (although I know 
enough exceptions, especially in user-space), but I have a different 
understanding of <uk/*>. In my understanding, it is not just kernel 
scope, it defines the lowest API of your platform/architecture. The most 
specialized Unikernel applications are going to use this API directly 
and would avoid any indirections in-between. Those applications would be 
written for Unikraft.
These headers should not depend on any implementation/header provided by 
a library in /lib, because this would imply that you force using this 
library to the application developer. So far so good. <errno.h> is part 
of the libc library and imagine that the application developer really 
does not want to use the libc. Of course you could say that the 
platforms currently anyways depend on a libc. However, such dependencies 
are defined in the build system by each platform. The <uk/*> headers 
have to apply to any (theoretical) platform/architecture and are not 
selectable or un-selectable. So it would be just wrong to add a 
dependency to a library here because you can't describe the dependency 
with the build system. If you would do it right and would want to have 
errno.h included, you would move errptr.h to a new library. But I think 
this is not worth doing it.
Simon

> - Yuri.
>
> Simon Kuenzer <simon.kuenzer@xxxxxxxxx> writes:
>
> > Hey Costin,
> >
> > On 23.08.2018 12:59, Costin Lupu wrote:
> > > Given that definitions from errptr.h are using together
> > > with errno numbers, it would make sense to simply include
> > > errno.h in errptr.h.
> > >
> > > Signed-off-by: Costin Lupu <costin.lupu@xxxxxxxxx>
> > > ---
> > >    include/uk/errptr.h | 1 +
> > >    1 file changed, 1 insertion(+)
> > >
> > > diff --git a/include/uk/errptr.h b/include/uk/errptr.h
> > > index 5806f73..27aa7d8 100644
> > > --- a/include/uk/errptr.h
> > > +++ b/include/uk/errptr.h
> > > @@ -36,6 +36,7 @@
> > >    #ifndef __UK_ERRPTR_H__
> > >    #define __UK_ERRPTR_H__
> > >    
> > > +#include <errno.h>
> > >    #include <uk/arch/types.h>
> > >    
> > >    #ifndef MAXERRNO
> > hum, errptr is just a mechanism to return error codes on functions that
> > only return pointers as data type. This header does itself not depend on
> > errno, nothing is used from errno. The idea was that you can use this
> > mechanism even with your own defined error codes. So, I would keep the
> > inclusion of errno.h separate. Just include errno.h on your libraries
> > API when these error codes are used there.
> >
> > Cheers,
> >
> > Simon
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel