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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
