On Mon, Sep 26, 2011 at 5:59 PM, Arnaud Lacombe <lacombar_at_gmail.com> wrote: > Hi, > > On Mon, Sep 26, 2011 at 7:48 PM, Benjamin Kaduk <kaduk_at_mit.edu> wrote: >> On Mon, 26 Sep 2011, Arnaud Lacombe wrote: >> >>> Hi, >>> >>> On Mon, Sep 26, 2011 at 4:34 PM, Brett Glass <brett_at_lariat.net> wrote: >>>> >>>> My personal preference would be to place portions of the directory tree >>>> which contain critical configuration information and are not written in >>>> normal use -- e.g. /etc and /boot -- >>>> >>> The problem with /boot on a dedicated partition is the the kernel, >>> since at least 8.x, is installed by default with a vast majority of >>> crap. That's all the .symbols, that 99% of FreeBSD users will never >>> uses. >> >> My recollection is that this is because kensmith forgot to take 'makeoptions >> DEBUG=-g' out of GENERIC when branching stable/8, and no one noticed until a >> couple of releases in, at which point it seemed consistent with POLA to just >> keep it there. Unfortunately I am not having much luck digging through mail >> archives trying to confirm that. >> I don't remember whether the plan was to turn it off on stable/9 or not. >> >>> >>> Beside that, the auto-partitionner refuses to work on <1G drive, which >>> is really ridiculous... >>> >>> FreeBSD 9.0BETA2 bases + games fit in 310MB, crap taken out. >> >> Can you even buy a spinning disk less than 50GB these days? >> > The storage world is not limited to spinning hardware. Take a 512MB > CF, put it in a soekris box, and you got an embedded system capable of > doing a whole bunch of stuff. > > Now, FreeBSD may no longer want to target such "niche" usage. > >> If you have hardware of that nature, you are almost certainly going to want >> to customize other aspects of the system (and if it's an under-provisioned >> system, are you really going to be doing this customization in-place?), at >> which point removing the extra stuff is minimal extra work. If a developer >> has to ask a user to do something (e.g. compile) in order to debug >> something, there is a huge hit in the response rate; having the symbols >> available in the general case can be helpful. >> > Then why don't you provide symbols for the whole system, including > binaries and libraries ? At least be consistent in your argument... > > And, yes, I have patches for that. For embedded this doesn't make sense with limited storage -- but that's what binutils enables: http://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-symbol-outside-the-build-target . I've linked against debug symbols when doing debugging with gdb and I can definitely attest to the fact that it's convenient and works well when trying to produce tiny embedded images. Thanks, -GarrettReceived on Mon Sep 26 2011 - 23:11:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC