[Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

[Ed Maste via lldb-commits]

emaste added inline comments.

================
Comment at: source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp:1
@@ +1,2 @@
+//===-- PlatformNetBSD.cpp -------------------------------------*- C++ -*-===//
+//
----------------
krytarowski wrote:
> labath wrote:
> > krytarowski wrote:
> > > labath wrote:
> > > > krytarowski wrote:
> > > > > labath wrote:
> > > > > > This platform code looks like it was copy-pasted from PlatformFreeBSD. Do you anticipate making significant changes here?
> > > > > > 
> > > > > > If not, it might be a good idea to share this code with FreeBSD in some way (in fact there is a comment here to make this share code with PlatformPOSIX). @emaste, what do you think about this?
> > > > > Yes... however I have bad experiences (mostly in Gnome) when we drag common code for rotted platforms like BSD4.4, BSD/OS and such in a single source tree paralyzing sane platform support.
> > > > So which one do you expect to rot first ?
> > > > 
> > > > Joke aside, I agree that this could be an issue, but I think if we put some thought into the design, we can limit the possible downsides of this approach. The other alternative, where we copy everything is not ideal either: we have had cases in the past, where we made a change in linux code, and then we needed to apply the exact same change in the freebsd version. So there is definitely some tradeoff to consider here...
> > > > 
> > > > In any case, I'm not trying to stop your changes because of this, but I think it's good to open this discussion in the early stages of the implementation... I don't know if you're aware but there are plans to move freebsd to the client-server model to follow linux, so if you make copies of the code, you may find out later that you may need to duplicate that work as well.
> > > I'm strongly for this to design and put common BSD code (for modern BSDs) into single library or module, limiting Free/Net specific pieces to their appropriate modules.
> > > 
> > > My requirement is to name the common parts as BSD, not FreeBSD. NetBSD isn't a variation of FreeBSD (neither e.g. Bitrig, which may come next -- there is already an active interest).
> > > 
> > > I was thinking how to do it, with virtual functions, inheritance, #ifdef magic... To make it clear, I don't use nor have FreeBSD to lonely design/redesign neither touch its platform support, therefor I request for active cooperation from the FreeBSD side.
> > >I'm strongly for this to design and put common BSD code (for modern BSDs) into single library or module, limiting Free/Net specific pieces to their appropriate modules.
> > 
> > >My requirement is to name the common parts as BSD, not FreeBSD. NetBSD isn't a variation of FreeBSD (neither e.g. Bitrig, which may come next -- there is already an active interest).
> > 
> > Sounds reasonable to me.
> > 
> > > I was thinking how to do it, with virtual functions, inheritance, #ifdef magic...
> > LLDB is a cross-platform tool, we can already remotely debug linux from windows and mac machines, etc. It would be great if this would eventually work for BSD platforms as well. For this, we need both freebsd and netbsd code in a single client binary, so #ifdefs are ruled out (at least in client code). But I think inheritance is perfect for this particular case of PlatformNetBSD -- just move the code to PlatformBSD and have Free/NetBSD inherit from that.
> > 
> > > To make it clear, I don't use nor have FreeBSD to lonely design/redesign neither touch its platform support, therefor I request for active cooperation from the FreeBSD side.
> > Let's see what FreeBSD has to say to this. :)
> > LLDB is a cross-platform tool, we can already remotely debug linux from windows and mac machines, etc. It would be great if this would eventually work for BSD platforms as well.
> 
> Sounds great!
> 
> > Let's see what FreeBSD has to say to this. :)
> 
> I opened the offer from my site. The code is already there. I'm waiting for the feedback.
> Joke aside, I agree that this could be an issue, but I think if we put some thought into the design, we can limit the possible downsides of this approach. The other alternative, where we copy everything is not ideal either: we have had cases in the past, where we made a change in linux code, and then we needed to apply the exact same change in the freebsd version. So there is definitely some tradeoff to consider here...

Yes - the sharing between Linux and FreeBSD was previously a bit of a mess: some Linux functionality existed in base classes, and some derived classes had nearly identical copy pasta.

> I don't know if you're aware but there are plans to move freebsd to the client-server model to follow linux, so if you make copies of the code, you may find out later that you may need to duplicate that work as well.

Indeed. Following the current FreeBSD model of in-processes debugging (ProcessMonitor and the ptrace interface) is likely to result in a lot of wasted effort and I wouldn't recommend that part.

> I was thinking how to do it, with virtual functions, inheritance, #ifdef magic... To make it clear, I don't use nor have FreeBSD to lonely design/redesign neither touch its platform support, therefor I request for active cooperation from the FreeBSD side.

A similar same question applied to the previous Linux/FreeBSD sharing, but we did not end up with a usable change -- but the Linux/FreeBSD differences are much more significant. @labath's suggestion of creating PlatformBSD and having PlatformFreeBSd and PlatformNetBSD derive from that makes sense to me.


Repository:
  rL LLVM

http://reviews.llvm.org/D13334