On 7/20/10, John Baldwin wrote:
> On Monday, July 19, 2010 11:50:37 pm Tim Judd wrote:
>> Hellos,
>>
>>
>> Of interest, I can get GEOM_UZIP kernel module as part of the kernel,
>> but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build
>> a kernel with GEOM_UZIP, will the relavant ZL
On Monday, July 19, 2010 11:50:37 pm Tim Judd wrote:
> Hellos,
>
>
> Of interest, I can get GEOM_UZIP kernel module as part of the kernel,
> but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build
> a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the
> kernel?
Yes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/07/19 20:50, Tim Judd wrote:
> Hellos,
>
>
> Of interest, I can get GEOM_UZIP kernel module as part of the kernel,
> but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build
> a kernel with GEOM_UZIP, will the relavant ZLIB pie
On Wed, Mar 17, 2004 at 09:36:39PM +0300, Roman Bogorodskiy wrote:
> static int
> new_open(struct proc *p, register struct open_args *uap)
Er, the first argument passed to a system call in 5.x is a `struct
thread', not a `struct proc'.
Cheers,
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PRO
John wrote:
> Also, you might consider using strncmp() to make the code a bit easier to
> read, i.e.:
>
> if (strncmp(name, "/tmp/", 5) == 0)
> printf("open(2): %s by pid %d (%s)\n", name, td->td_proc->p_pid,
> td->td_proc->p_comm);
Thank you very much, it
Jacques wrote:
> That's only correct for machines with 32-bit ints. In any case, POSIX
> only specifies that pid_t is a signed integer type... it could be any
> size supported by the implementation. For portability, you probably
> want to cast to the `biggest' type and use the appropriate print
On Wed, Mar 17, 2004 at 04:45:30PM +0100, Toni Andjelkovic wrote:
> On Wed, Mar 17 2004 (17:00:02 +0200), Artis Caune wrote:
> > "pid_t" is signed int type, or am I missing something?
>
> You are right, pid_t is __int32_t, which is signed, so "%d"
> is the correct format.
That's only correct for
On Wed, Mar 17 2004 (17:00:02 +0200), Artis Caune wrote:
> "pid_t" is signed int type, or am I missing something?
You are right, pid_t is __int32_t, which is signed, so "%d"
is the correct format.
I assumed that in this case, the signed integer overflowed,
so maybe interpreting it as an unsigned
On Tuesday 16 March 2004 11:39 am, Roman Bogorodskiy wrote:
> Hi,
>
> I hope it's a right place for kernel module programming related
> questions, in another case I'd be glad if you point me to the right
> maillist.
>
> So, my aim is to log every file opening in `/tmp' dir. I've wrote a simpl
"pid_t" is signed int type, or am I missing something?
try this one:
static int
new_open (struct proc *p, register struct open_args *uap)
{
pid_t pid;
pid = p->p_pid;
printf("open(2): pid: %d\n", pid);
return (open(p,uap));
}
On Wed, 17 Mar 2004 17:24:51 +0300, Roman Bogorodskiy
<[EMAI
Toni wrote:
> pid_t is an unsigned number, so try "%u" in printf() instead.
> There's no need to cast a pid_t to int.
Doesn't help. It shows wrong pid's again...
-Roman Bogorodskiy
pgp0.pgp
Description: PGP signature
On Tue, Mar 16, 2004 at 07:39:56PM +0300, Roman Bogorodskiy wrote:
+> I hope it's a right place for kernel module programming related
+> questions, in another case I'd be glad if you point me to the right
+> maillist.
+>
+> So, my aim is to log every file opening in `/tmp' dir. I've wrote a
On Tue, Mar 16 2004 (19:39:56 +0300), Roman Bogorodskiy wrote:
[...]
> printf("open(2): %s pid: %i\n", name, (int)p->p_pid);
[...]
> Mar 16 19:15:44 nov kernel: open(2): /tmp/asfdasfsaf pid: -1002890624
pid_t is an unsigned number, so try "%u" in printf() instead.
There's no need to
On Sat, Sep 21, 2002 at 06:50:09AM +0200, Christian Zander wrote:
>
> Maybe it helps to get an idea of what memory allocation sizes we
> are talking about for the NVIDIA driver. For every single OpenGL
> client in the system memory case (no AGP), the resource manager
> has to allocate ~1MB (in mu
On Sat, Sep 21, 2002 at 12:42:07AM -0600, M. Warner Losh wrote:
>
> this is false. If you load the module from the boot loader there
> is no difference between that and having it be actually compiled
> into the kernel in terms of resource allocation.
>
> However, this is true if you intend to lo
In message: <20020915203835.GA3497@gallium>
Dominic Marks <[EMAIL PROTECTED]> writes:
: disadvantages:
: some drivers need to be able to allocate a large chunk of contiguous
: memory to operate correctly, this means some drivers cant work when not
: compiled in to the kernel (becaus
> I think it was imported in the doc tree as well.
Thanks for reminding me.
I just worked through the newbus driver article
and from there stumbled on
http://www.netbsd.org/Documentation/kernel/programming.html
Regards,
Marc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscr
Hi Panagiotis,
> http://www.daemonnews.org/200010/blueprints.html
thank you very much for this link.
> I think it was imported in the doc tree as well.
Have not looked there for quite a while.
Perhaps there is something on drivers as well.
Regards,
Marc
To Unsubscribe: send mail to [EMAIL
On Tue, Apr 03, 2001 at 04:38:40AM -0700, Marc van Woerkom wrote:
> I'm looking for some docs on our kernel module architecture.
>
> Do we have something more decent than
>
> http://packetstorm.securify.com/papers/unix/bsdkern.htm
Check out:
http://www.daemonnews.org/200010/blueprints.html
On Tue, 1 Feb 2000, Derek White wrote:
> Hey folks,
>
> I just wanted to know if anyone could point out a good
> online resource like a tutorial or developer guide
> that explains kernel module development under FreeBSD.
See http://thc.pimmel.com/files/thc/bsdkern.html Although not necessarily
20 matches
Mail list logo
