I'm revisiting the project to determine device dependency in the kernel,
and I've run into a situation where net/if.c requires the ether device,
but no device appears to require net/if.c directly.
sys/conf/files says that net/if.c is "standard", but I have no idea what
that means in terms of build
On Mon, 24 Jun 2002, Paul Herman wrote:
> On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote:
>
> > So we either need to have a compelling solution or get a
> > committer to step in and make up our minds for us.
>
> I think the best thing to do is file a PR for this.
On Mon, 24 Jun 2002, Paul Herman wrote:
> On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote:
>
> > So we either need to have a compelling solution or get a
> > committer to step in and make up our minds for us.
>
> I think the best thing to do is file a PR for this.
On Sun, 23 Jun 2002, Paul Herman wrote:
> You see the problem as a deficiency in the implementation itself,
> and wish to protect the user from shooting themselves in the foot.
>
> Not only do I think that's impossible[*], I choose to fight for my
> right to shoot myself in the foot as quickly an
On Sun, 23 Jun 2002, Matthew D. Fuller wrote:
> Well, a daemon would have a BETTER chance, though nowhere near a
> guarantee. The theory being that the daemon would check every so often
> (5 minutes sounds good to me), whereas with the library, you potentially
> could not check for days, dependi
On Sat, 18 May 2002, Paul Herman wrote:
> Well, unlink and remove are the same in my vocabulary. The file is
> removed when you unlink it, but the will lock remain until you
> close it.
Well, unlink and remove are apparently not the same in the man page for
unlink(2), as excepted here:
If
[I'm bringing the discussion back to -hackers, since it was omitted in
your original reply, Paul. To get everyone up to speed, Paul suggested
that calling unlink() _before_ close() should solve the race condition
mentioned in my original message. However, that still leads to
corruption, and we'r
On Mon, 13 May 2002, Geoffrey C. Speicher wrote:
> On Thu, 2 May 2002, Matthew D. Fuller wrote:
>
> > I'll see if I can put some time over the next few days into delving into
> > it and at least getting the first step (of making the locking work more
> > useful
On Thu, 2 May 2002, Matthew D. Fuller wrote:
> I'll see if I can put some time over the next few days into delving into
> it and at least getting the first step (of making the locking work more
> usefully) work.
Hi Matt. Just wondering if you've made any progress on making pw use a
lockfile. I
On Thu, 2 May 2002, Matthew D. Fuller wrote:
> Well, the stab didn't go because nobody was interested 8-)
Sorry --- I was interested, but I didn't see your original message. This
problem has been biting me (and a client) in the ass for quite some time.
> I actually had in mind some farther-r
On Sat, 9 Mar 2002 04:52:25 -0600, Matthew D. Fuller wrote:
[in regard to multiple concurrent pw(8) processes hosing master.passwd]
> The reason for this is that the only file pw(8) locks is
> /etc/master.passwd.new when it copies into it.
[snip]
> If anybody's interested, I could take a stab
11 matches
Mail list logo
