krytarowski added inline comments.

================
Comment at: source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp:1
@@ +1,2 @@
+//===-- PlatformNetBSD.cpp -------------------------------------*- C++ -*-===//
+//
----------------
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.


Repository:
  rL LLVM

http://reviews.llvm.org/D13334



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to