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
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 of me.. :)
Thanks,
--
Hiten Pandya
http://jfs4
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...
=
regards,
Hiten Pandya
<[EMAIL PR
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
:The "md" driver I committed today is mostly a proof-of-concept thing
:which came out of a chat with Peter Wemm.
:
:It acts like a disk in all aspects, although it will be hard to boot
:from it :-)
:
:It will do very simple compression, in that a sector (512bytes)
:which is filled with the same ch
The "md" driver I committed today is mostly a proof-of-concept thing
which came out of a chat with Peter Wemm.
It acts like a disk in all aspects, although it will be hard to boot
from it :-)
It will do very simple compression, in that a sector (512bytes)
which is filled with the same character
Re-nicing wont help as I have just confirmed that the problem occurs
if I run MAME, exit MAME and then get on the net.
Very wierd... after running MAME, the serial port is unusable for
ppp unless I reboot. Just doing a DNS lookup causes several silo
overflows. MAME does something very strange
On Sun, 2 May 1999, Matthew Thyer wrote:
> I have been investigating the silo overflow situation for some time.
>
> I can trigger them every time by the following action:
>
> - Run M.A.M.E. (Multi arcade machine emulator) and then try to
> download something. (I am using user mode ppp).
Can yo
I have been investigating the silo overflow situation for some time.
I can trigger them every time by the following action:
- Run M.A.M.E. (Multi arcade machine emulator) and then try to
download something. (I am using user mode ppp).
I believe that the sio driver is its own worst enemy in that
23 matches
Mail list logo
