Re: [PATCH 00/44] Update RTEMS-specific header files to latest FreeBSD versions

[Corinna Vinschen <vinschen at redhat dot com>]

On Aug  9 18:24, Richard Earnshaw (lists) wrote:
> On 09/08/18 17:46, Gedare Bloom wrote:
> > On Thu, Aug 9, 2018 at 9:13 AM, Sebastian Huber
> > <sebastian.huber@embedded-brains.de> wrote:
> >> On 09/08/18 15:12, Eric Blake wrote:
> >>>
> >>> On 08/09/2018 01:08 AM, Sebastian Huber wrote:
> >>>>
> >>>> This is an RTEMS-specific patch set. It is a preparation to update the
> >>>> libbsd
> >>>> (a port of FreeBSD code to RTEMS, e.g. the network stack) to new FreeBSD
> >>>> baseline.
> >>>>
> >>>> The patch set does two things:
> >>>>
> >>>> 1. It updates several header files imported from FreeBSD using the
> >>>> commits from
> >>>>     FreeBSD.
> >>>>
> >>>> 2. It removes the kernel space content from some files and includes a
> >>>>     <machine/_kernel_*.h> file instead.  This allows to use the Newlib
> >>>> provided
> >>>>     header files with different FreeBSD baselines.
> >>>
> >>>
> >>> This series is full of poorly-formatted commit messages:
> >>>
> >>>> ae@FreeBSD.org (1):
> >>>>    Follow the RFC6980 and silently ignore following IPv6 NDP messages
> >>>>      that had the IPv6 fragmentation header: o Neighbor Solicitation o
> >>>>      Neighbor Advertisement o Router Solicitation o Router Advertisement
> >>>>      o Redirect
> >>>
> >>>
> >>>> glebius (2):
> >>>
> >>> ...
> >>>>
> >>>>    Garbage collect IFCAP_POLLING_NOCOUNT. It wasn't used since very
> >>>>      beginning of polling(4). The module always ignored return value from
> >>>>      driver polling handler.
> >>>>
> >>>
> >>>> jhb (4):
> >>>>    Add a mmap flag (MAP_32BIT) on 64-bit platforms to request that a
> >>>>      mapping use an address in the first 2GB of the process's address
> >>>>      space. This flag should have the same semantics as the same flag on
> >>>>      Linux.
> >>>>    Add a new fo_fill_kinfo fileops method to add type-specific
> >>>>      information to struct kinfo_file. - Move the various fill_*_info()
> >>>>      methods out of kern_descrip.c and into the various file type
> >>>>      implementations. - Rework the support for kinfo_ofile to generate a
> >>>>      suitable kinfo_file object for each file and then convert that to a
> >>>>      kinfo_ofile structure rather than keeping a second, different set of
> >>>>      code that directly manipulates type-specific file information. -
> >>>>      Remove the shm_path() and ksem_info() layering violations.
> >>>>    Retire the unimplemented MAP_RENAME and MAP_NORESERVE flags to
> >>>>      mmap(2). Older binaries are still permitted to use these flags.
> >>>>    Add a new file operations hook for mmap operations. File type-specific
> >>>>      logic is now placed in the mmap hook implementation rather than
> >>>>      requiring it to be placed in sys/vm/vm_mmap.c. This hook allows new
> >>>>      file types to support mmap() as well as potentially allowing mmap()
> >>>>      for existing file types that do not currently support any mapping.
> >>>>
> >>>> jtl (1):
> >>>>    Add the "TCP Blackbox Recorder" which we discussed at the developer
> >>>>      summits at BSDCan and BSDCam in 2017.
> >>>>
> >>>> kib (8):
> >>>>    Implement read(2)/write(2) and neccessary lseek(2) for posix shmfd.
> >>>>      Add MAC framework entries for posix shm read and write.
> >>>>    Add MAP_EXCL flag for mmap(2). It should be combined with MAP_FIXED,
> >>>>      and prevents the request from deleting existing mappings in the
> >>>>      region, failing instead.
> >>>>    Implement process-shared locks support for libthr.so.3, without
> >>>>      breaking the ABI. Special value is stored in the lock pointer to
> >>>>      indicate shared lock, and offline page in the shared memory is
> >>>>      allocated to store the actual lock.
> >>>
> >>> ...
> >>>>
> >>>>    Add a place for a driver to report rx timestamps in nanoseconds from
> >>>>      boot for the received packets.
> >>>>    Use hardware timestamps to report packet timestamps for SO_TIMESTAMP
> >>>>      and other similar socket options.
> >>>
> >>>
> >>>>
> >>>> pkelsey (1):
> >>>>    This is an implementation of the client side of TCP Fast Open (TFO)
> >>>>      [RFC7413]. It also includes a pre-shared key mode of operation in
> >>>>      which the server requires the client to be in possession of a shared
> >>>>      secret in order to successfully open TFO connections with that
> >>>>      server.
> >>>>
> >>>> rrs (1):
> >>>>    This commit brings in a new refactored TCP stack called Rack. Rack
> >>>>      includes the following features: - A different SACK processing
> >>>>      scheme (the old sack structures are not used). - RACK (Recent
> >>>>      acknowledgment) where counting dup-acks is no longer done instead
> >>>>      time is used to knwo when to retransmit. (see the I-D) - TLP (Tail
> >>>>      Loss Probe) where we will probe for tail-losses to attempt to try
> >>>>      not to take a retransmit time-out. (see the I-D) - Burst mitigation
> >>>>      using TCPHTPS - PRR (partial rate reduction) see the RFC.
> >>>
> >>>
> >>> Please reformat the commit messages to have a SHORT summary (60-70
> >>> characters), then a blank line, then the rest of the description, rather
> >>> than diving right in to description that git then uses as the overlong
> >>> subject line.
> >>>
> >>
> >> I would like to keep the messages as is. This makes it easier to compare
> >> upstream FreeBSD changes with changes imported to Newlib.
> >>
> > 
> > In this case, since the commits come from a third party repository, we
> > would like to request inclusion of the commits in newlib without
> > modification. This allows us to more easily update to future versions
> > of the third party code, and provides a cleaner history/provenance of
> > the code.
> > 
> 
> Surely *adding* one extra line (followed by one blank line) as a summary
> at the head of the commit won't really interfere with such tracking.
> We're not asking you to reformat any of the remaining text.
> 
> R.

Right.  I fully agree with Eric and Richard.

If you really need to keep track of the upstream patches, add a
"cherry-picked from" line and use the SHA-1 for tracking.  That's much
better and easier than tracking via full text.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature