[parted-devel] porting to FreeBSD

[Siavosh Benabbas]

Hi,

On 3/2/07, Debarshi 'Rishi' Ray <debarshi.ray at gmail.com> wrote:
> > Personally I don't think that is very good as it is copy-pasting and
> > can introduce errors, not that I have much to do with parted
> > development, just my thoughts.
>
> I do not understand. Could you just re-phrase or be a bit more verbose?

I was saying that  writing two signal handlers is not very good.
Because the code for the one parameter one is a subset of the other.
Any change to that shared code should be applied at two places which
might introduce errors. Any way I understand that as the shared code
is a few lines this is not a big deal.

> > The problem with FreeBSD is a bit different, freebsd has the sigaction
> > but it lacks many  MACROs one would check the value of struct
> > siginfo_t.si_code against!
>
> Well this is not identical to the Hurd scenario, but nevertheless very
> similar because the absense of these macros is preventing you from taking
> full leverage out of the 'sigaction' function to give detailed information
> about the signal that was caught and what caused them.
>
> > We could place a #ifdef block around any MACRO that sa_flag is checked
> > against like this:
> >
> >  switch(x.si_code) {
> > #ifdef SEGV_MAPERR
> >     case SEGV_MAPERR:
> >     //.....
> > #endif
> >    //...
> >    default:
> >    //....
> >  }
>
> This is one possibility. I would like to know if only _some_ of these
> macros are absent or _all_ of them are absent. eg., is it the case that
> SEGV_MAPERR is absent, while SEGV_ACCERR is present? Do we see such a
> behaviour in all the *BSDs?
>

Well, unfortunately the list of macros present is not in the man page,
it is scattered in different header files (for different signals). But
I think that the general macro constants like (SI_USER, SI_QUEUE,
...), and does related to ILL and FPE are present and anything else is
missing. By the way the kernel does set the si_code value in all
cases. I don't know if this is a FreeBSD issue or a BSD one.

> > I don't think this is a good approach because when the "default:" code
> > is executed you can't be sure which values x.si_code is checked
> > against.
>
> If for a particular signal, some of the macros are present while others
> are not, then the above approach will atleast give us some detailed
> information in those cases where they are present.
>

Agreed.

> > Any way this is a FreeBSD brokenness and I think the best way
> > to go for FreeBSD is to ignore its sigaction capabilities for now.
>
> If there is no uniform pattern in which these macros are present or absent,
> we can do something like:
> #ifdef SA_SIGINFO
> #ifdef SEGV_MAPPERR
> #ifdef <any missing sigaction macro>
> ...
> #define USE_SIGACTION
> ...
> #endif
> #endif
> #endif
> ...and then depending upon whether USE_SIGACTION is defined or undefined,
> we use 'sigaction' or 'signal'.

This sounds good. Another possibility is to just disable sigaction for
FreeBSD and document this behaviour. The FreeBSD kernel guys already
know this and it is fixed in their latest CVS branch.

Regards,
Siavosh