On Mon, 29 Sep 2014 12:08:07 -0400 chas williams - CONTRACTOR <c...@cmf.nrl.navy.mil> wrote:
> On Wed, 24 Sep 2014 15:14:39 -0400 (EDT) > Benjamin Kaduk <ka...@mit.edu> wrote: > > > (1) Should we install .la files for shared libraries? > > > > We are now using libtool to build things. Some people like to > > install the .la file for external consumers to use. Some people > > don't. Debian falls in the latter category, which leans me toward > > it as well. > > Do not ship unless we really have to. If we start shipping it we will > always need to ship it after that. I agree with not shipping a .la, but was the question here to ship a .la vs a .pc, or just not ship anything? I thought we'd be providing a pkg-config .pc file for these, but I'm not sure if that's been brought up at all. > > (3) Dropping the Netscape plugin and related bits from our tree > > > ... > > So, do we have consensus in favor of removing these bits from the > > openafs tree? > > It's unmaintainable since it can't be (reasonably) tested. Remove it. Any of this kind of crud can be added back if anyone complains. Also, it was mentioned that "Netscape" doesn't exist anymore, but I'm not sure if that's actually true for some value of "exist". This was for netscape's web server, which I think is now called Oracle iPlanet Web Server and has an open fork called heliod. Not that it matters (and I'm not saying it's even compatible with that if it works at all), but the "thing" that it's for is not entirely nonexistent. > > (4) changing fileserver tuning > > > > The fileserver lets you pass arguments like -S and -L for "small" and > > "large" setups. But ... the "large" one is actually quite small, by > > today's standards. We probably ought to update what those coarse-grain > > settings do, and the defaults as well. > > Good luck with getting agreement about small and large. Perhaps these > should be more like the client (with respecting to its auto-tuning of > the cache size) and use some percentage of memory on the machine. Yes, these 'small' and 'large' distinctions are useless. I agree that having something autotune parameters based on memory (like the CM bases many decisions based on cache size) is the best way to go. Then it's not "large" vs "small", it's "16G of ram" vs "16M of ram". This should be intuitive, since almost all (or even all) of the options that just change numbers are memory/speed tradeoffs. I don't feel this needs to happen on a big version boundary (so it wouldn't block branching or 1.8 release etc), but that would be nice. Something like '-auto 16G' can be done fairly easily; you just need to pick values for different memory amounts. For something like '-auto 20%' I think you'd need to add some platform-specific code for memory probing, which is a little more work. If that is implemented, we can just have the default be something like '-auto 20%', and have all other parameters autotuned from that. I would very much prefer something like that to exist, rather than adding another "size class", or even just changing the defaults. > > (5) configure arguments for pam/kauth > ... > > whether src/kauth bits get installed. However, the pam modules we > > provide are only useful in a kaserver-style environment (i.e., > > krb4). Currently, pam defaults to enabled, and kauth defaults to > > disabled, and I have not seen anything to indicate that we wish to > > reenable kauth for the 1.8 branch. > ... > > addition to controlling whether the src/kauth bits get installed. > > Does that seem reasonable? > > Why keep either for the 1.8 branch? You can stay on the 1.6 stream if > you need this. Maintaining stuff that is already done better by others > (pam_krb5, krb5) seems like a waste of time. iirc pam_afs is so entrenched with openafs rx and lwp that pulling it out is annoying (we'd just have a complete copy of rx and lwp and perhaps some other things). But maybe it is possible to reduce that to a reasonable level if someone wanted to. I have a patchset to get it to build for sparcv9 that I've been unsure of what to do with. Perhaps that could be the impetus for myself or SNA to pull it out into a separate small project, where buildsystem etc changes for it won't bother the rest of openafs. > > Going through the output more carefully, I also found --disable-gtx, > > --disable-uss, --enable-bitmap-later, and --disable-unix-sockets, > > which I > > I don't see the reason for --disable-gtx. --disable-uss I thought --disable-gtx was to avoid ncurses. I thought I saw somewhere that maybe this could just be --without-ncurses, and have basically the same result? > bitmap-later (and fast-restart) are both just poor versions of DAFS. > They should be deprecated for 1.8 (accept the options and print a > warning that the user should switch to DAFS). These really are not necessarily replaceable by DAFS. They are effectively replaced by DAFS for everyone except for the people that complain that DAFS is still too slow for their purposes. I cannot speak for them (the research labs), but I thought they were still of that opinion and would appreciate these options not going away completely yet. fast-restart was already removed, and turned into a runtime option for the fileserver (-unsafe-nosalvage). bitmap-later could get the same treatment, and really seems a bit orthogonal to DAFS. If bitmap-later actually works and doesn't introduce serious issues (iirc this has been debated, but I haven't looked at it much so I can't say), it would be useful to have on all the time. It just delays loading/calculating the vnode bitmap until it's actually needed; it's even more lazy-evaluation (for one particular structure) than DAFS is. A quick glance suggests that bitmap-later is easy to turn into a runtime option; the #define doesn't change structure definitions or anything like that. > I don't know the reason behind unix sockets. Unix domain sockets > gives you a different permission model I guess. Disabling unix sockets means that *sync protocols go through localhost ports instead of unix sockets on disk. It can make things very insecure on the fileserver, since anyone locally can issue fssync-debug and salvsync-debug commands. As far as I'm aware, the only reason the non-unix-sockets code paths are even there is for Windows; maybe the config option is there so it could be run on Unix to see if the code paths actually work. I don't see a reason to keep the config option around; someone using it without knowing what it does could be dangerous. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
