Re: some PRs

From: Kris Kennaway (kris_at_obsecurity.org)
Date: 07/18/04

  • Next message: Pawel Jakub Dawidek: "Re: some PRs" 
    Date: Sun, 18 Jul 2004 10:51:00 -0700
To: Robert Millan <zeratul2@wanadoo.es>

    On Sun, Jul 18, 2004 at 06:51:42PM +0200, Robert Millan wrote:
    > On Sun, Jul 18, 2004 at 06:16:49PM +0300, Giorgos Keramidas wrote:
    > > On 2004-07-18 15:33, Robert Millan <zeratul2@wanadoo.es> wrote:
    > > >
    > > > I think it's useful for compatibility.
    > >
    > > In general, I'm not against compatibility. However, what's the end of
    > > this route? To create one special device node in /dev for every
    > > possible errno value? :-(
    >
    > I don't claim that /dev/full is useful just for the sake of it. Your argument
    > (that having a device just for each errno value is silly) is something I
    > basicaly agree with.
    >
    > But if some applications depend on it, it's still helpful for portability.
    > I don't know what support for native compatibility is expected or planned for
    > FreeBSD, but I know you have a Ports Collection with thousands of packages,
    > and this might minimaly reduce the work of your port maintainers. IMHO, you
    > should ask the people working in the Ports Collection for their opinion before
    > taking a decision.
    >
    > (Note this patch comes from the context of the Debian GNU/kFreeBSD porting
    > effort, in which we port Debian GNU/Linux packages, which are a bit more
    > likely to introduce Linuxisms than the average candidate for FreeBSD Ports.
    > Thus, our requirements might differ somewhat.)

    There's no mention of /dev/full in the build logs (e.g. configure
    script output) of any of the 11000-odd ports in the ports collection.

    Kris

  • Next message: Pawel Jakub Dawidek: "Re: some PRs"

    Relevant Pages

    • Re: some PRs
      ... > In general, I'm not against compatibility. ... FreeBSD, but I know you have a Ports Collection with thousands of packages, ... (Note this patch comes from the context of the Debian GNU/kFreeBSD porting ... effort, in which we port Debian GNU/Linux packages, which are a bit more ...
      (freebsd-arch)
    • Re: HEADSUP: arp-v2 has been committed
      ... I renamed this flag bit to RTF_LLDATA because only the ... Perhaps it's because these ports run on OS ... there is still a level of compatibility, ... It's just that this makes FreeBSD 8 ...
      (freebsd-current)
    • Re: HEADSUP: arp-v2 has been committed
      ... I renamed this flag bit to RTF_LLDATA because only the ... Perhaps it's because these ports run on OS ... there is still a level of compatibility, ... It's just that this makes FreeBSD 8 ...
      (freebsd-net)
    • Re: HEADS UP! MAJOR change to FreeBSD/sparc64
      ... > programs running with 32-bTT, ... approaches involving compatibility syscalls / libc hacks. ... pretty sure there's no way to do this without completely breaking the ABI. ... This means lots and lots and lots of patches in the ports tree. ...
      (freebsd-current)
    • RE: HEADSUP: arp-v2 has been committed
      ... Right now I am also a bit leaning towards reintroducing ... I renamed this flag bit to RTF_LLDATA because only the ... Perhaps it's because these ports run on OS ... there is still a level of compatibility, ...
      (freebsd-net)