These changes will allow top to run in a jail, or proceed on even though
certain stats can not be obtained. Unfortunatly you do loss some error
messages when doing so.
Ps. If I should be submitting these elsewhere please let me know.
dff -c machine.c newmachine.c > machine.c.diff
*** mac
>
>
>
>That would be pretty cool, why don't you use the gnats:
>http://www.freebsd.org/send-pr.html
>or just "send-pr"
>
>to submit your changes?
>
>One idea would be to fail gracefully, when unable to read kvm and
>such and keep the -j flag idea you had.
>
Thats a great idea it didn't even cross
* Jon Ringuette <[EMAIL PROTECTED]> [020401 19:20] wrote:
> Sorry to bother everyone here but I have a quick question (or I guess
> what I hope is a quick question). I have made some modifications to
> src/usr.bin/machine.c to allow TOP to run in a jail (I have mostly just
> taken out kvm_read
Sorry to bother everyone here but I have a quick question (or I guess
what I hope is a quick question). I have made some modifications to
src/usr.bin/machine.c to allow TOP to run in a jail (I have mostly just
taken out kvm_read's ) and zero'd out alot of information that is not
available to
Jordan Hubbard wrote:
>
> http://www.cs.helsinki.fi/linux/linux-kernel/2002-13/0063.html
>
> Matt or Theo indeed!
I saw that; pretty amusing, even if it wasn't him. By far a
better joke that most.
Good thing I didn't publish my RFC on "PlainText" encryption
for S/MIME encapsulated email... i
Here are the diffs for the mbuf changes I am trying...
#diff -c mbuf.h mbuf.h.new
*** mbuf.h Mon Apr 1 17:27:33 2002
--- mbuf.h.new Mon Apr 1 17:27:17 2002
***
*** 79,84
--- 79,87
struct ifnet *rcvif; /* rcv interface */
int len;
On Mon, Apr 01, 2002 at 02:54:05PM -0500, Zhihui Zhang wrote:
>
> I am wondering how many modules in all are compiled during the kernel
> compilation (make depend; make). Is there any configuration file I can
> look into to find out all the module names?
How about src/sys/modules/Makefile?
--
C
http://www.cs.helsinki.fi/linux/linux-kernel/2002-13/0063.html
Matt or Theo indeed!
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Michael Smith wrote:
> > One way to obtain this information is to write a program
> > that uses vm86() calls to read the first N sectors of a
> > BIOS disk, then read the same area using the protected mode
> > drivers. When you get a unique MD5 hash match between the
> > BIOS and the boot device,
I am wondering how many modules in all are compiled during the kernel
compilation (make depend; make). Is there any configuration file I can
look into to find out all the module names?
Thanks,
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the bod
On Mon, Apr 01, 2002 at 08:46:46PM +0200, Simon 'corecode' Schubert wrote:
Hi Simon,
> gcc 3.0.4 on the other hand ships with lots of more standardized
> headers. if i am informed correctly, 5.0-c uses gcc 3.0.4?
Close but no cigar :-)
flynn@saioa# uname -srn
FreeBSD saioa.energyhq.tk 5.0-CURR
> One way to obtain this information is to write a program
> that uses vm86() calls to read the first N sectors of a
> BIOS disk, then read the same area using the protected mode
> drivers. When you get a unique MD5 hash match between the
> BIOS and the boot device, you're there.
This won't work
On Mon, 1 Apr 2002 10:55:22 +0200 (CEST) Alexander Leidinger <[EMAIL PROTECTED]>
wrote:
> On 31 Mär, Simon 'corecode' Schubert wrote:
>
> > that's right. but as terry said, it seems to be a bad idea to use some
> > headers that don't fit the libs.
> > i tried to patch the headers coming with 4.
Dmitry Konyshev wrote:
>Could anyone please tell me if there's any way to find out which
>device the system booted from in a user application. The loader
>sets loaddev and currdev vars, but I see no way to transfer them to
>the user environment.
Luigi Rizzo posted patches to commu
>Could anyone please tell me if there's any way to find out which
>device the system booted from in a user application. The loader
>sets loaddev and currdev vars, but I see no way to transfer them to
>the user environment.
kenv(8) allows you to read the kernel/loader environment.
On Mon, Apr 01, 2002 at 09:11:03PM +0400, Maxim Konovalov wrote:
...
> >Could anyone please tell me if there's any way to find out which
> >device the system booted from in a user application. The loader
...
> In recent -current we have sysctl machdep.guessed_bootdev.
recently merged to -
On 20:34+0400, Apr 1, 2002, Dmitry Konyshev wrote:
> Hello hackers,
>
>Could anyone please tell me if there's any way to find out which
>device the system booted from in a user application. The loader
>sets loaddev and currdev vars, but I see no way to transfer them to
>the user e
Hello hackers,
Could anyone please tell me if there's any way to find out which
device the system booted from in a user application. The loader
sets loaddev and currdev vars, but I see no way to transfer them to
the user environment.
--
Best regards,
Dmitry
In message <[EMAIL PROTECTED]>,
Alexander Leidi
nger writes:
> On 31 Mär, Simon 'corecode' Schubert wrote:
People, it appears that I (Cyril Schubert) am being confused with Simon
Schubert. Please trim me, [EMAIL PROTECTED], from the cc list. I'm
already subscribed to the lists and don't need
Wilko Bulte wrote:
> While not stepping up to solve the world politics: the US government
> claiming the right to define the law for everything is unnerving to
> lots of non-US (and US I suppose) people alike.
>
> GPS is just one of these things..
I disagree. The problem is the engineers.
When
subscribe
Murat AdývarDepartment of MathematicsAnkara
University06100, Tandogan, Ankara
On Mon, Apr 01, 2002 at 12:00:47AM -0800, Terry Lambert wrote:
> [EMAIL PROTECTED] wrote:
> > > > Hopefully European GPS project (Galileo) will provide an alternative.
> > > > It still has a long way to go though.
> > >
> > > Galileo strikes me as unnecessary, unless the receivers will be
> > > ch
On 31 Mär, Simon 'corecode' Schubert wrote:
> that's right. but as terry said, it seems to be a bad idea to use some
> headers that don't fit the libs.
> i tried to patch the headers coming with 4.4-S and lang/gcc30 (because
> the one from the base system doesn't provide a proper c++ stl
> implem
On 31 Mär, Terry Lambert wrote:
> Probably this means you are still getting a mix of GNU and
> ICC C++ header files, and need to carefully look at your
> include paths.
Yes, it has ${LOCALBASE}/intel/compiler50/include/ in the include path.
There are some intel specific includes. We don't have i
24 matches
Mail list logo
