Someone should move atomicio.c into nfs-utils/support/nfs. There are
currently two copies, in idmapd and spnfsd, and I'm about to add a third.
I'll move it if no one has a better idea or beats me to it.
On Fri, 2010-07-16 at 15:35 -0400, Jim Rees wrote:
> Someone should move atomicio.c into nfs-utils/support/nfs. There are
> currently two copies, in idmapd and spnfsd, and I'm about to add a third.
> I'll move it if no one has a better idea or beats me to it.
I agree with this move as I have a label mapping daemon based off of
idmapd which uses it as well (although not merged yet). My patch set
actually moves this file to support/nfs as well.
Dave
David P. Quigley wrote:
I agree with this move as I have a label mapping daemon based off of
idmapd which uses it as well (although not merged yet). My patch set
actually moves this file to support/nfs as well.
I don't suppose you'd like to isolate just the move and submit that?
strlcat and strlcpy should probably go too.
On 07/16/2010 04:53 PM, Jim Rees wrote:
> David P. Quigley wrote:
>
> I agree with this move as I have a label mapping daemon based off of
> idmapd which uses it as well (although not merged yet). My patch set
> actually moves this file to support/nfs as well.
>
> I don't suppose you'd like to isolate just the move and submit that?
I'll take care of it...
>
> strlcat and strlcpy should probably go too.
Anything else?
steved.
Steve Dickson wrote:
> strlcat and strlcpy should probably go too.
Anything else?
I don't see any other library functions that should move. Configure should
check for strlcat and strlcpy, and not compile them if there are system
versions. Again, I'll do that if no one beats me to it.
On a related note, I've been using benny's pnfs-nfs-utils.git tree as a base
for adding the block layout helper, as suggested by the wiki. Is that
correct?
On Fri, 2010-07-16 at 18:06 -0400, Jim Rees wrote:
> Steve Dickson wrote:
>
> > strlcat and strlcpy should probably go too.
> Anything else?
>
> I don't see any other library functions that should move. Configure should
> check for strlcat and strlcpy, and not compile them if there are system
> versions. Again, I'll do that if no one beats me to it.
>
> On a related note, I've been using benny's pnfs-nfs-utils.git tree as a base
> for adding the block layout helper, as suggested by the wiki. Is that
> correct?
Just got back from dinner and I'm heading out soon for the weekend but
here is the patch that I have. It should apply on top of
2ef57222b10a91f4b96a06808d05a47e8f4c14f7 and moves strlcat and strlcpy
as well. The only think you might have to check is I know at some point
some changes were made to cfg.c and cfg.h make sure the ones I have in
this patch are the new ones instead of the old ones. I'd take a closer
look but I'm short on time here.
Dave
Hey David,
On 07/16/2010 06:33 PM, David P. Quigley wrote:
> On Fri, 2010-07-16 at 18:06 -0400, Jim Rees wrote:
>> Steve Dickson wrote:
>>
>> > strlcat and strlcpy should probably go too.
>> Anything else?
>>
>> I don't see any other library functions that should move. Configure should
>> check for strlcat and strlcpy, and not compile them if there are system
>> versions. Again, I'll do that if no one beats me to it.
>>
>> On a related note, I've been using benny's pnfs-nfs-utils.git tree as a base
>> for adding the block layout helper, as suggested by the wiki. Is that
>> correct?
>
> Just got back from dinner and I'm heading out soon for the weekend but
> here is the patch that I have. It should apply on top of
> 2ef57222b10a91f4b96a06808d05a47e8f4c14f7 and moves strlcat and strlcpy
> as well. The only think you might have to check is I know at some point
> some changes were made to cfg.c and cfg.h make sure the ones I have in
> this patch are the new ones instead of the old ones. I'd take a closer
> look but I'm short on time here.
Thanks for being so proactive... but... there is no utils/idmapd/cfg.[ch]
files in my upstream repo... so where is that coming from??
steved.
On 07/16/2010 06:33 PM, David P. Quigley wrote:
> On Fri, 2010-07-16 at 18:06 -0400, Jim Rees wrote:
>> Steve Dickson wrote:
>>
>> > strlcat and strlcpy should probably go too.
>> Anything else?
>>
>> I don't see any other library functions that should move. Configure should
>> check for strlcat and strlcpy, and not compile them if there are system
>> versions. Again, I'll do that if no one beats me to it.
>>
>> On a related note, I've been using benny's pnfs-nfs-utils.git tree as a base
>> for adding the block layout helper, as suggested by the wiki. Is that
>> correct?
>
> Just got back from dinner and I'm heading out soon for the weekend but
> here is the patch that I have. It should apply on top of
> 2ef57222b10a91f4b96a06808d05a47e8f4c14f7 and moves strlcat and strlcpy
> as well. The only think you might have to check is I know at some point
> some changes were made to cfg.c and cfg.h make sure the ones I have in
> this patch are the new ones instead of the old ones. I'd take a closer
> look but I'm short on time here.
>
>
Question: Is there a reason need a private version of queue.h, instead
of using the one ins /usr/include/sys?
steved.
On Mon, 2010-07-19 at 11:33 -0400, Steve Dickson wrote:
>
> On 07/16/2010 06:33 PM, David P. Quigley wrote:
> > On Fri, 2010-07-16 at 18:06 -0400, Jim Rees wrote:
> >> Steve Dickson wrote:
> >>
> >> > strlcat and strlcpy should probably go too.
> >> Anything else?
> >>
> >> I don't see any other library functions that should move. Configure should
> >> check for strlcat and strlcpy, and not compile them if there are system
> >> versions. Again, I'll do that if no one beats me to it.
> >>
> >> On a related note, I've been using benny's pnfs-nfs-utils.git tree as a base
> >> for adding the block layout helper, as suggested by the wiki. Is that
> >> correct?
> >
> > Just got back from dinner and I'm heading out soon for the weekend but
> > here is the patch that I have. It should apply on top of
> > 2ef57222b10a91f4b96a06808d05a47e8f4c14f7 and moves strlcat and strlcpy
> > as well. The only think you might have to check is I know at some point
> > some changes were made to cfg.c and cfg.h make sure the ones I have in
> > this patch are the new ones instead of the old ones. I'd take a closer
> > look but I'm short on time here.
> >
> >
> Question: Is there a reason need a private version of queue.h, instead
> of using the one ins /usr/include/sys?
>
> steved.
Hello Steve,
At one point there was a cfg.c and cfg.h for idmapd. That was
probably when I first made this patch a year or so ago. I use guilt for
patch management so I've been rebasing those patches onto newer versions
for a while. Its possible that those files were moved or removed since
then. I think I remember hearing that someone redid the config files for
nfs. If that is the case cfg.c and cfg.h can go away. It is very
possible that they were just rolled forward with the patch rebasing.
Additionally if queue.h from /usr/include/sys is what is being used now
we can get rid of the private copy from my patch as well. I didn't have
a reason for keeping a private copy other than the fact the idmapd was
using it and I was going to as well so I moved it into the support
directory. I should have given the patch a bit more of a look over
before I left for the weekend but I was running really short on time
when I sent it out.
Dave