Re: CVS commit: src/sbin/newfs

[Greg Troxel]

Taylor R Campbell  writes:

> Well, what happened is:
>
> 1. I was drafting posix_memalign and aligned_alloc for libbsdmalloc in
>response to the thread about static program size yesterday, and
>carefully reading the specs -- POSIX 2018, C11 -- to make sure I
>got all the details right.
>
> 2. I saw a silly restriction in C11, that aligned_alloc(A, S) requires
>A to divide S.
>
> 3. For the sake of encouraging portable code, I figured we should
>enforce that restriction, so I went ahead and did that in both the
>libbsdmalloc front end I was writing and in jemalloc.  (This caused
>a bunch of tests to start failing.)
>
> 4. I audited all the uses of aligned_alloc in tree to make sury they
>meet the restriction (which fixed the tests).
>
> 5. Someone pointed out that the silly restriction that was imposed in
>C11 had actually been lifted in C17:
>
> (C11) The value of alignment shall be a valid alignment
> supported by the implementation and the value of size shall be
> an integral multiple of alignment.
>
> (C17) If the value of alignment is not a valid alignment
> supported by the implementation the function shall fail by
> returning a null pointer.
>
> 6. So I reverted the jemalloc enforcement of the C11 restriction, and
>reverted the fixes made to conform to it, and removed the
>restriction in the new libbsdmalloc code, and we're more or less
>back to where we started.
>
> Except I am now reminded that I updated t_posix_memalign.c to verify
> this silly restriction of aligned_alloc, so I'd better go fix that
> before a bunch of tests start failing again!

Thanks for taking the time to explain so thoroughly.  So we are back to
status quo ante-fixum, which is by definition always ok :-)

Re: CVS commit: src/sbin/newfs

[Taylor R Campbell]

> Date: Wed, 05 Jul 2023 07:03:09 -0400
> From: Greg Troxel 
> References: <20230705105858.33080f...@cvs.netbsd.org>
> 
> "Taylor R Campbell"  writes:
> 
> > Revert "newfs(8): Ensure A divides S before aligned_alloc(A, S)."
> >
> > C17 lifted this restriction.
> 
> I know we have only two toolchains maintained in tree, but did we really
> decide to require C17?

Well, what happened is:

1. I was drafting posix_memalign and aligned_alloc for libbsdmalloc in
   response to the thread about static program size yesterday, and
   carefully reading the specs -- POSIX 2018, C11 -- to make sure I
   got all the details right.

2. I saw a silly restriction in C11, that aligned_alloc(A, S) requires
   A to divide S.

3. For the sake of encouraging portable code, I figured we should
   enforce that restriction, so I went ahead and did that in both the
   libbsdmalloc front end I was writing and in jemalloc.  (This caused
   a bunch of tests to start failing.)

4. I audited all the uses of aligned_alloc in tree to make sury they
   meet the restriction (which fixed the tests).

5. Someone pointed out that the silly restriction that was imposed in
   C11 had actually been lifted in C17:

(C11) The value of alignment shall be a valid alignment
supported by the implementation and the value of size shall be
an integral multiple of alignment.

(C17) If the value of alignment is not a valid alignment
supported by the implementation the function shall fail by
returning a null pointer.

6. So I reverted the jemalloc enforcement of the C11 restriction, and
   reverted the fixes made to conform to it, and removed the
   restriction in the new libbsdmalloc code, and we're more or less
   back to where we started.

Except I am now reminded that I updated t_posix_memalign.c to verify
this silly restriction of aligned_alloc, so I'd better go fix that
before a bunch of tests start failing again!

Re: CVS commit: src/sbin/newfs

[Robert Elz]

Date:Tue, 13 Sep 2016 00:50:30 +0100
From:Sevan Janiyan 
Message-ID:  <2d30ad57-2341-3b08-1d78-32b468cd5...@netbsd.org>

  | I can't seem to find the 4.3BSD-Reno release notes at the moment, but
  | the convention is interim releases do not count.
  | There are examples of that where 4.2BSD is being referenced in inherited
  | man pages when in-fact the tools actually showed up in 4.1{a,b,c}.

I think it is reasonable to ignore 4.1a (etc) for this kind of purpose,
but as I recall, 4.3 Reno & Tahoe were really full releases

kre

Re: CVS commit: src/sbin/newfs

[Sevan Janiyan]

On 13/09/2016 00:09, matthew green wrote:
> that never stopped them being referenced before.  infact, the macros
> appear know what they mean because it transforms:
> 
>.Bx 4.3 tahoe .
> 
> into:
> 
>The shells file format appeared in 4.3BSD-Tahoe.
> 
> ie, it capitalises and adds the dash.  i think it matter because there
> was a very long time between each of 4.3, reno, tahoe, 4.4 (closed)
> and 4.4-lite (and lite2).

For memfs support, it was actually covered in the 4.4BSD Release notes.
https://groups.google.com/d/msg/comp.unix.bsd/hZYO7xTDqQ8/NE-S-HWH9-wJ

"We  have also added amemory-based filesystem that runs in pageable
memory, allowing  large temporary filesystems without requiring
dedicated physical memory."

I can't seem to find the 4.3BSD-Reno release notes at the moment, but
the convention is interim releases do not count.
There are examples of that where 4.2BSD is being referenced in inherited
man pages when in-fact the tools actually showed up in 4.1{a,b,c}.



Sevan

re: CVS commit: src/sbin/newfs

[matthew green]

Sevan Janiyan writes:
> On 12/09/2016 22:02, matthew green wrote:
> > wouldn't "09/06/89" put it in 4.3RENO ?  from bsd-family-tree:
> > 
> > 4.3BSD Reno 1990-06-29 [QCU], [DOC]
> > 
> > 
> > .mrg.
> 
> Reno & Tahoe along with 4.1{a,b,c} were interim/beta releases.

that never stopped them being referenced before.  infact, the macros
appear know what they mean because it transforms:

   .Bx 4.3 tahoe .

into:

   The shells file format appeared in 4.3BSD-Tahoe.

ie, it capitalises and adds the dash.  i think it matter because there
was a very long time between each of 4.3, reno, tahoe, 4.4 (closed)
and 4.4-lite (and lite2).


.mrg.

re: CVS commit: src/sbin/newfs

[matthew green]

> Log Message:
> Memory File System support appeared in 4.4BSD, implemented as an extension to
> newfs(8). So while newfs may have appeared in 4.2BSD, MFS support was later.
> https://svnweb.freebsd.org/csrg/sbin/newfs/Makefile?r1=39047=39051
> Adjust HISTORY.
> Bump date.

wouldn't "09/06/89" put it in 4.3RENO ?  from bsd-family-tree:

4.3BSD Reno 1990-06-29 [QCU], [DOC]


.mrg.