On Wed, 27 Mar 2002, Robert Watson wrote:
> On Wed, 27 Mar 2002, Hiten Pandya wrote:
>
> > According to me, the utility shouldn't be using a hardcoded path to the
> > booting kernel, as this would affect kernels which were made by:
> >
> > makeoptions KERNEL=foo#Build kernel "foo" and ins
--- Robert Watson <[EMAIL PROTECTED]> wrote:
> I'd avoid your later changes involving describing how getbootfile() relies
> on sysctl in the kgmon(8) man page. That's an implementation detail of
> the API, not of kgmon, and while it probably won't change, putting the
> information there increases
On Wed, 27 Mar 2002, Hiten Pandya wrote:
> According to me, the utility shouldn't be using a hardcoded path to the
> booting kernel, as this would affect kernels which were made by:
>
> makeoptions KERNEL=foo#Build kernel "foo" and install "/foo"
>
> What are your suggestions?
The u
--- Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> How about http://people.FreeBSD.org/~keramida/diff/kgmon.txt ?
Hmm, the patch looks pretty good, but we can use a bit of rewording which
will reflect what the code does. Something like the following:
-- START --
Extract the name list from the s
On Wed, 27 Mar 2002, Hiten Pandya wrote:
> How come the kgmon(8) is still refering to /kernel? Is this a bug or I
> am unaware of something? :) If it is a bug, than I probably someone can
> commit the change in behalf of me.. :)
Same reason that most man pages that say where the kernel is stil
On 2002-03-27 16:44, Hiten Pandya wrote:
> --- Robert Watson <[EMAIL PROTECTED]> wrote:
> > I've committed a tweak to the man page, but think that the page may
> > actually be wrong in a more general sense: kgmon appears to use
> > getbootfile() so will actually use whatever path the sytem booted
--- Robert Watson <[EMAIL PROTECTED]> wrote:
> I've committed a tweak to the man page, but think that the page may
> actually be wrong in a more general sense: kgmon appears to use
> getbootfile() so will actually use whatever path the sytem booted with.
> While by default that will be /boot/kerne
I've committed a tweak to the man page, but think that the page may
actually be wrong in a more general sense: kgmon appears to use
getbootfile() so will actually use whatever path the sytem booted with.
While by default that will be /boot/kernel/kernel, it may be something
else, in which case kg
On Wed, 27 Mar 2002, Hiten Pandya wrote:
:> Generate diffs -- send-pr.
:
:Does this apply to all the manual pages in -CURRENT? where /kernel
:should be /boot/kernel/kernel? If this is the case, then I can just
:send one or two big PRs which have the patches.
:
:What are your suggestions? :)
Thi
> Generate diffs -- send-pr.
Does this apply to all the manual pages in -CURRENT? where /kernel
should be /boot/kernel/kernel? If this is the case, then I can just
send one or two big PRs which have the patches.
What are your suggestions? :)
Thanks,
--
Hiten Pandya
http://jfs4bsd.sf.net - JF
On Wed, 27 Mar 2002, Hiten Pandya wrote:
:Hi all,
:
:According to -current, isnt the kernel file located /boot/kernel?
:
:How come the kgmon(8) is still refering to /kernel? Is this a bug or I
:am unaware of something? :) If it is a bug, than I probably someone can
:commit the change in behalf
Hiten Pandya wrote:
> MH> The lock order verification is not part of the mtx
> MH> API. It's debugging
> MH> stuff activated by default in -CURRENT. If you do
> MH> not want to see these
> MH> warnings, remove ``options WITNESS'' from your
> MH> kernel conf or patch the
> MH> code to solve the p
MH> The lock order verification is not part of the mtx
MH> API. It's debugging
MH> stuff activated by default in -CURRENT. If you do
MH> not want to see these
MH> warnings, remove ``options WITNESS'' from your
MH> kernel conf or patch the
MH> code to solve the problem :-)
hi,
i know that bit..
Hiten Pandya wrote:
> hi all,
> sorry for running -current.. but i am an enthusiastic
> and challenging man...(boy)...
>
> anyways.. whats a mutex and a lock order reversal...
> if you could point to some good manual on these
> subjects... thanks...
>
> help is appreciated...
>
> thanks again..
Hiten Pandya wrote:
> one more question... if there is a lock order
> reversal.. is there a way that can be solved.. for
> e.g. by using on of the MTX_XX things...
The lock order verification is not part of the mtx API. It's debugging
stuff activated by default in -CURRENT. If you do not want t
hi maxime...
thanks very very much.. now i get it...,
its like.. a mutex is a lock, which is used when
things are done in parralel and to avoid corruption of
the data which is being processed... i took an example
of the way i used to lock files in PERL, in order to
avoid multiple writes at the sam
16 matches
Mail list logo
