do we run the CTFCONVERT on kernel modules?
It is run from the Makefile of the kernel which is generated by the
config(8) program.
Bye,
Alexander.
--
Whenever I feel like exercise, I lie down until the feeling passes.
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B00
...meaning, I see the following line in "sys/conf/kmod.mk", but that
is a CTFMERGE command.
.if defined(MK_CTF) && ${MK_CTF} != "no"
${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${OBJS}
.endif
Where do we run the CTFCONVERT on kerne
2011/12/29 Kostik Belousov :
> On Thu, Dec 29, 2011 at 12:53:19PM +, Chris Rees wrote:
>> 2011/12/29 Kostik Belousov :
>> > On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
>> >> 2011/12/28 Kostik Belousov :
>> >> > On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
>> >> >>
On Thu, Dec 29, 2011 at 12:53:19PM +, Chris Rees wrote:
> 2011/12/29 Kostik Belousov :
> > On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
> >> 2011/12/28 Kostik Belousov :
> >> > On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
> >> >> 2011/12/28 Kostik Belousov :
> >> >
2011/12/29 Kostik Belousov :
> On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
>> 2011/12/28 Kostik Belousov :
>> > On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
>> >> 2011/12/28 Kostik Belousov :
>> >> > On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
>> >> >>
On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
> 2011/12/28 Kostik Belousov :
> > On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
> >> 2011/12/28 Kostik Belousov :
> >> > On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
> >> >> On 28 December 2011 12:21, Daniel O
2011/12/28 Kostik Belousov :
> On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
>> 2011/12/28 Kostik Belousov :
>> > On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
>> >> On 28 December 2011 12:21, Daniel O'Connor wrote:
>> >> >
>> >> > On 28/12/2011, at 22:07, Chris Rees wr
On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
> 2011/12/28 Kostik Belousov :
> > On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
> >> On 28 December 2011 12:21, Daniel O'Connor wrote:
> >> >
> >> > On 28/12/2011, at 22:07, Chris Rees wrote:
> >> >> Is there a simple way t
2011/12/28 Kostik Belousov :
> On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
>> On 28 December 2011 12:21, Daniel O'Connor wrote:
>> >
>> > On 28/12/2011, at 22:07, Chris Rees wrote:
>> >> Is there a simple way to check for existence of a driver? I could
>> >> even check for /dev/sn
On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
> On 28 December 2011 12:21, Daniel O'Connor wrote:
> >
> > On 28/12/2011, at 22:07, Chris Rees wrote:
> >> Is there a simple way to check for existence of a driver? I could
> >> even check for /dev/sndstat, though that doesn't seem eleg
On 28/12/2011, at 22:07, Chris Rees wrote:
> Is there a simple way to check for existence of a driver? I could
> even check for /dev/sndstat, though that doesn't seem elegant to me...
kldstat -v, but really /dev/sndstat seems simpler and just as effective.
--
Daniel O'Connor software and networ
On 28 December 2011 12:21, Daniel O'Connor wrote:
>
> On 28/12/2011, at 22:07, Chris Rees wrote:
>> Is there a simple way to check for existence of a driver? I could
>> even check for /dev/sndstat, though that doesn't seem elegant to me...
>
> kldstat -v, but really /dev/sndstat seems simpler and
Hi all,
Apologies for the noob question-- I'm trying to stop audio/oss causing
panics when loaded on a system that includes DEVICE sound in its
kernel config (which has been GENERIC for ~6months now :))
Is there a simple way to check for existence of a driver? I could
even check for /dev/sndstat
Just tried dys_sysctl. It doesn't work as well.
Below are the results I got:
r...@olimpico-freebsd 22:04:17 /usr/share/examples/kld/dyn_sysctl # [0] uname -a
FreeBSD olimpico-freebsd 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Nov
22 21:35:15 MSK 2010
r...@olimpico-freebsd:/usr/obj/usr/src/sys/GENERIC
On Mon, Nov 22, 2010 at 5:38 AM, Dmitry Krivenok
wrote:
> Hello Hackers,
> Recently I installed 8.1 on my laptop and recompiled the kernel.
> The system works fine, but I have a strange problem with my own
> trivial kernel module.
> I noticed that printf function doesn't produce any output (accord
Hello Hackers,
Recently I installed 8.1 on my laptop and recompiled the kernel.
The system works fine, but I have a strange problem with my own
trivial kernel module.
I noticed that printf function doesn't produce any output (according to
dmesg) if I call it from a module. Note, that the same modul
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
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?
I love to torture myself by putting BSD in environments it's not
norma
On 25 Jun 2010, at 10:28, Andriy Gapon wrote:
>
> Here's a patch that is supposed to do the right thing for dtrace.
> Perhaps I should have put the new code under __amd64__, but I decided to go
> more
> "generic" and check for module's ELF type (ET_REL).
>
> Reviews and testing are welcome!
I
Gary Jennejohn wrote:
> IMO if you're going to make the binaries in base non-executable
> you might just as well delete them.
The chmod is reversible without having to recover the base binaries
from somewhere.
___
freebsd-hackers@freebsd.org mailing li
Here's a patch that is supposed to do the right thing for dtrace.
Perhaps I should have put the new code under __amd64__, but I decided to go more
"generic" and check for module's ELF type (ET_REL).
Reviews and testing are welcome!
diff --git a/cddl/contrib/opensolaris/lib/libdtrace/common/dt_im
On Thu, 24 Jun 2010 09:54:45 -0700
Ted Faber wrote:
> On Thu, Jun 24, 2010 at 08:29:57AM -0700, Ted Faber wrote:
> > On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote:
> > > I also have this in make.conf:
> > > CUPS_OVERWRITE_BASE=yes
> > > WITHOUT_LPR=yes
> > >
> > > which print/cups-ba
On Thu, Jun 24, 2010 at 08:29:57AM -0700, Ted Faber wrote:
> On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote:
> > I also have this in make.conf:
> > CUPS_OVERWRITE_BASE=yes
> > WITHOUT_LPR=yes
> >
> > which print/cups-base uses to do make any lpr related binaries in
> > /usr/bin non-exec
On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote:
> I also have this in make.conf:
> CUPS_OVERWRITE_BASE=yes
> WITHOUT_LPR=yes
>
> which print/cups-base uses to do make any lpr related binaries in
> /usr/bin non-executable, so they are skipped over and the cups
> specific ones in /usr/loc
* Mike Meyer wrote:
> Maybe it's time for /usr/sbin/lpwrapper, to do the same thing for
> print systems?
In my opinion, we should just rename mailwrapper to whateverwrapper and
list the lpr programs in there as well.
--
Ed Schouten
WWW: http://80386.nl/
pgpn1LzLEWm9v.pgp
Description: PGP s
* Andrew Reilly wrote:
> On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote:
> > in /etc/src.conf - WITHOUT_LPR=yes
> >
> > and these symbolic links in /usr/bin
> > lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp ->
> > /usr/local/bin/lp
> > lrwxr-xr-x 1 root wheel
On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote:
> in /etc/src.conf - WITHOUT_LPR=yes
>
> and these symbolic links in /usr/bin
> lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp ->
> /usr/local/bin/lp
> lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions ->
On 24 Jun 2010, at 9:23, Gary Jennejohn wrote:
> On Wed, 23 Jun 2010 18:15:09 -0700
> Ted Faber wrote:
>
>> (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr
>> commands from cupsd, though it's evidently a bit of a dangerous idea.)
>>
> [trimmed Cc]
>
> I use cupsd and have th
On Thu, Jun 24, 2010 at 10:45 AM, Alex Dupre wrote:
> Tom Evans ha scritto:
>> make delete-old removes old deprecated files, not files that weren't
>> built because of src.conf options.
>
> I think you are wrong:
> http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?
Tom Evans ha scritto:
> make delete-old removes old deprecated files, not files that weren't
> built because of src.conf options.
I think you are wrong:
http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?rev=1.66
--
Alex Dupre
_
On Thu, Jun 24, 2010 at 10:21 AM, Andrew Reilly wrote:
> On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote:
>> in /etc/src.conf - WITHOUT_LPR=yes
>>
>> and these symbolic links in /usr/bin
>> lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp ->
>> /usr/local/bin/lp
>> lrwxr-
Andriy Gapon writes:
> Yes, you are absolutely correct. This comes from the fact that amd64 uses
> simple
> objects files (aka .o) as kernel modules and i386 uses full-blow dso.
The obvious question is: since, as I understand, amd64's solution is
superior, what would it take to s
On Thu, Jun 24, 2010 at 8:23 AM, Gary Jennejohn
wrote:
> On Wed, 23 Jun 2010 18:15:09 -0700
> Ted Faber wrote:
>
>> (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr
>> commands from cupsd, though it's evidently a bit of a dangerous idea.)
>>
> [trimmed Cc]
>
> I use cupsd and ha
On Thu, 24 Jun 2010 10:30:26 +0200
Alban Hertroys wrote:
> On 24 Jun 2010, at 9:23, Gary Jennejohn wrote:
>
> > On Wed, 23 Jun 2010 18:15:09 -0700
> > Ted Faber wrote:
> >
> >> (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr
> >> commands from cupsd, though it's evidently a
On Wed, 23 Jun 2010 18:15:09 -0700
Ted Faber wrote:
> (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr
> commands from cupsd, though it's evidently a bit of a dangerous idea.)
>
[trimmed Cc]
I use cupsd and have these settings to get around using the base system
lp stuff:
in
preceeds /usr/bin in my path so I can use the lpr
commands from cupsd, though it's evidently a bit of a dangerous idea.)
Basically if the linker you're using to compile isn't /usr/bin/ld you
may have problems building kernel modules.
The easiest way to detect this is to get the -v o
On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote:
> I have to admit that I'm more than a little surprised that this
> problem does not affect modules that in src, but maybe that's because
> I don't know all that much about FreeBSD's build infrastructure. Are
> the src modules being linke
st looks up the section that contains the sysinits directly via the
> ELF metadata that is already present.
Yes, you are absolutely correct. This comes from the fact that amd64 uses
simple
objects files (aka .o) as kernel modules and i386 uses full-blow dso.
> As far as I can tel
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon wrote:
>
> Which also brings the question - what arch(s) is affected?
> I tested on amd64.
This should explain it. It looks to me like i386 uses kern/link_elf.c
as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can
only find the sectio
On Wed, Jun 23, 2010 at 10:10:59AM +0300, Andriy Gapon wrote:
> on 23/06/2010 10:02 Andriy Gapon said the following:
> > I don't dispute that it is found broken in particular environments, I just
> > think
> > that the analysis could be incorrect.
>
> Which also brings the question - what arch(s)
On Wednesday 23 June 2010 09:10:59 Andriy Gapon wrote:
> on 23/06/2010 10:02 Andriy Gapon said the following:
> > I don't dispute that it is found broken in particular environments, I
> > just think that the analysis could be incorrect.
Ok.
>
> Which also brings the question - what arch(s) is af
on 23/06/2010 10:02 Andriy Gapon said the following:
> I don't dispute that it is found broken in particular environments, I just
> think
> that the analysis could be incorrect.
Which also brings the question - what arch(s) is affected?
I tested on amd64.
--
Andriy Gapon
___
t;> On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
>>>> I saw similar behaviour a couple of years ago when I switched from
>>>> using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules.
>>>> The problem ended up being a change in the
aw similar behaviour a couple of years ago when I switched from
> >> using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules.
> >> The problem ended up being a change in the linker script used by GNU
> >> ld for linking kernel modules. It used to always put so
to gcc 4.3.0 to compile some out-of-tree KLD modules.
>> The problem ended up being a change in the linker script used by GNU
>> ld for linking kernel modules. It used to always put some magic
>> symbols used by the linker to implement things like sysinits into the
>> modu
On Wed, Jun 23, 2010 at 02:38:06AM +0200, Hans Petter Selasky wrote:
> It appears many kmods are broken because the linker is stripping away static
> data declared with the section attribute in FreeBSD 8.1-RC1.
>
>
>
> I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port
> m
change in the linker script used by GNU
> ld for linking kernel modules. It used to always put some magic
> symbols used by the linker to implement things like sysinits into the
> module. It was changed to only provide those symbols, which
> apparently means that the linker would discard
flags are bfd library equivalents of ET_EXEC and ET_DYN elf
flags. Absence of both of these flags means ET_REL, which is a type of our
amd64 kernel modules.
The code all resides in kld.c and acts only kernel modules that are either
auto-loaded via kld_current_sos or explicitly added with add-kld.
I use
on 22/06/2010 01:00 Navdeep Parhar said the following:
>
> I'm not so sure about this. There is code inside the second switch that runs
> whether sh_size is 0 or not. Either all of it is pointless code (when sh_size
> is 0) or or you'll make sure that it still runs, right?
It's definitely point
On Tue, Jun 22, 2010 at 12:34:49AM +0300, Andriy Gapon wrote:
> on 21/06/2010 23:44 Navdeep Parhar said the following:
> > On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote:
> >> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote:
> >>> on 21/06/2010 18:43 John Baldwin said the follow
on 21/06/2010 23:44 Navdeep Parhar said the following:
> On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote:
>> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote:
>>> on 21/06/2010 18:43 John Baldwin said the following:
np@ has a patch to gdb to fix this for kgdb. I haven't comm
On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote:
> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote:
> > on 21/06/2010 18:43 John Baldwin said the following:
> > > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as
> > > it
> > > patched gdb internals and wa
On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote:
> on 21/06/2010 18:43 John Baldwin said the following:
> > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it
> > patched gdb internals and wasn't in a kgdb-specific place, but I'm not
sure of
> > a better way to fix
on 21/06/2010 18:43 John Baldwin said the following:
> np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it
> patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure
> of
> a better way to fix kgdb.
Oh, yes, section mapping is done in common gdb code.
P
ame address. This is correct only for .text which is normally the first
section
> described in a header.
>
> DTrace situation is even worse, because don't even take into account module
base
> address, not speaking of section relative addresses.
>
> Perhaps we should put some
Trace situation is even worse, because don't even take into account module base
address, not speaking of section relative addresses.
Perhaps we should put some sh_addr values into amd64 kernel modules that would
match calculations done in link_elf_load_file.
Or should we replicate logic from link_elf
Hi,
I'm writing a new kernel module which can not be run with another
module. If both run then bad things will happen and the kernel will
fall over. Fixing the modules so they can be run together is not a
option, so I wanted to code something in this new module which would
A) Check if the other mo
s to NSS and writing kernel modules?
>
> These are not similar things and you don't need kernel modules for NSS.
> For kernel modules, you might try reading:
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/index.html
> http://www.freebsd.org/doc/en_
Z.C.B. wrote:
Have just been looking at sitting down and looking at writing a few
things, but I am a bit lost on where to start. Any suggestions on
things to read in regards to NSS and writing kernel modules?
These are not similar things and you don't need kernel modules for NSS.
For k
Have just been looking at sitting down and looking at writing a few
things, but I am a bit lost on where to start. Any suggestions on
things to read in regards to NSS and writing kernel modules?
___
freebsd-hackers@freebsd.org mailing list
http
Pietro Cerutti wrote:
> Adding "netgraph/bluetooth" and "firewire/fwe" in the MODULES_OVERRIDE
> list won't build the parent netgraph and firewire modules, but adding
> "netgraph" and "firewire" will build lots of unneeded and unwanted
> modules.
netgraph/netgraph and firewire/firewire.
--
Skip
Hi Hackers,
I'm stripping down my kernel, and I use the MODULES_OVERRIDE option in make.conf
Here's the question:
I need support for if_fwe and ng_bluetooth, but I can't find a way to
build /*ONLY*/ the required modules, instead of building
/*EVERYTHING*/ under firewire/ and under netgraph/
Addi
Howdy,
One of my new years resolutions was to become a bit more masochistic, so I
set out to see if I could build a kernel (and modules) without "options
INET" on HEAD.
This works flawlessly for the kernel part, but there are tons of issues when
building modules -- various problems encountered du
On 2004-06-16 11:35:33 +0530, ravi wrote:
> Hi,
>
> I wanted to know how to write the dynamic kernel modules in FreeBSD.
> Please send me the relevant information.
>
> Regards,
> N Ravi
Hi Ravi,
I forwarded your mail to the FreeBSD mailing list
[EMAIL PROTECTED]
You sh
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
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 simple
"syscall" module which replaces open(2) syscall. My new open(2) loo
In message: <[EMAIL PROTECTED]>
"masta" <[EMAIL PROTECTED]> writes:
: Does the -CURRENT kldload(8), and/or loader(8), understand how to
: decompress gzip/bzip kernel modules? I'm assuming it is possible, but I
: haven't seen that done in the wild, or do
Howdy,
Does the -CURRENT kldload(8), and/or loader(8), understand how to
decompress gzip/bzip kernel modules? I'm assuming it is possible, but I
haven't seen that done in the wild, or documented.
Thanks
On Fri Mar 21, 2003 at 07:47:42PM +0300, Yar Tikhiy wrote:
> On Fri, Mar 21, 2003 at 11:25:01AM -0500, The Anarcat wrote:
> > On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote:
> > >
> > > Yeah, it's all right to compile modules w/o the kernel, but that's
> > > not exactly what I was askin
On Fri, Mar 21, 2003 at 11:25:01AM -0500, The Anarcat wrote:
> On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote:
> >
> > Yeah, it's all right to compile modules w/o the kernel, but that's
> > not exactly what I was asking about. My question was whether "option
> > FOO" lines from a kerne
t;> > >
TA>> > > Excuse my stupid question, but I seem to have no time to do the
TA>> > > investigation by myself right now so I'd be glad to receive a brief
TA>> > > answer from someone who has the information.
TA>> > >
TA>> > >
ad to receive a brief
> > answer from someone who has the information.
> >
> > As far as I can see, kernel modules should be built along with the
> > kernel for the only reason of keeping their mutual interfaces in
> > sync, has a source file defining such an interface ch
but I seem to have no time to do the
> > > investigation by myself right now so I'd be glad to receive a brief
> > > answer from someone who has the information.
> > >
> > > As far as I can see, kernel modules should be built along with the
> > > kernel f
ad to receive a brief
> > answer from someone who has the information.
> >
> > As far as I can see, kernel modules should be built along with the
> > kernel for the only reason of keeping their mutual interfaces in
> > sync, has a source file defining such an inter
On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote:
> Hi there,
>
> Excuse my stupid question, but I seem to have no time to do the
> investigation by myself right now so I'd be glad to receive a brief
> answer from someone who has the information.
>
> As far as
On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote:
> Hi there,
>
> Excuse my stupid question, but I seem to have no time to do the
> investigation by myself right now so I'd be glad to receive a brief
> answer from someone who has the information.
>
> As far as
Hi there,
Excuse my stupid question, but I seem to have no time to do the
investigation by myself right now so I'd be glad to receive a brief
answer from someone who has the information.
As far as I can see, kernel modules should be built along with the
kernel for the only reason of ke
In message: <[EMAIL PROTECTED]>
Peter Jeremy <[EMAIL PROTECTED]> writes:
: That said, I feel that a single number (or variable name) is too
: coarse and the "do I need to bump the version" decision is too fuzzy.
: Unfortunately, I can't think of anything better that wouldn't incur
: an
On Thu, Mar 06, 2003 at 09:41:04AM -0700, M. Warner Losh wrote:
>In message: <[EMAIL PROTECTED]>
>Peter Jeremy <[EMAIL PROTECTED]> writes:
>: Disadvantages:
>: - Needs grunt-work to write the #defines
>: - Kernel symbols reported by nm(1) look strange (unless we patch
>: binutils to u
The patch that I posted here can't possibly work, but there are other
ways to deal. I'm investigating.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In message: <[EMAIL PROTECTED]>
Peter Jeremy <[EMAIL PROTECTED]> writes:
: Disadvantages:
: - Needs grunt-work to write the #defines
: - Kernel symbols reported by nm(1) look strange (unless we patch
: binutils to understand our versioning scheme).
: - May present problems to '##' bui
In message: <[EMAIL PROTECTED]>
Andrew Gallatin <[EMAIL PROTECTED]> writes:
: My company ships a binary driver ("ethernet" network, and character
: device) built on 4.1.1-R, and it has continued to work at least until
: 4.7-R. I'd like to see that same level of ABI stability throughout
In message: <[EMAIL PROTECTED]>
Sean Kelly <[EMAIL PROTECTED]> writes:
: On Wed, Mar 05, 2003 at 09:59:01PM -0700, M. Warner Losh wrote:
: > Here's a simple patch. However, it is a total suck-ass kludge (and
: > that's being generous). The ABI isn't THE ABI, but rather a
: > collectio
At 2003-03-06T07:09:40Z, Peter Jeremy <[EMAIL PROTECTED]> writes:
> 1) If you update any of those kernels, the updated kernel and updated
> modules will be written into /boot/FOO/ as appropriate. BUT old modules
> that weren't rebuilt (eg 3rd party modules) will remain in /boot/FOO/. If
> the ne
M. Warner Losh writes:
> In message: <[EMAIL PROTECTED]>
> Sean Kelly <[EMAIL PROTECTED]> writes:
> : Has anyone ever considered embedding some sort of identifier in kernel
> : modules to keep them from being loaded with the wrong kernel?
>
> Actu
On Thu, Mar 06, 2003 at 01:49:20AM -0600, Sean Kelly wrote:
>> +/*
>> + * Define the version. Change the symbol name when things get too
>> + * incompatible. version_5_1 means the 'ABI compatible with FreeBSD 5.1'
>> + */
>> +char __version_5_1 = 1;
>...
>
>Wouldn't it make more sense to have a s
On Wed, Mar 05, 2003 at 09:59:01PM -0700, M. Warner Losh wrote:
>Here's a simple patch. However, it is a total suck-ass kludge (and
>that's being generous). The ABI isn't THE ABI, but rather a
>collection of ABIs. These ABIs change slowly and there is a certain
>range that work together.
I thin
On Wed, Mar 05, 2003 at 09:59:01PM -0700, M. Warner Losh wrote:
> Here's a simple patch. However, it is a total suck-ass kludge (and
> that's being generous). The ABI isn't THE ABI, but rather a
> collection of ABIs. These ABIs change slowly and there is a certain
> range that work together. Hi
On Wed, Mar 05, 2003 at 11:33:31PM -0600, Kirk Strauser wrote:
>At 2003-03-06T03:08:52Z, Sean Kelly <[EMAIL PROTECTED]> writes:
>
>> Has anyone ever considered embedding some sort of identifier in kernel
>> modules to keep them from being loaded with the wrong kernel?
>
1 - 100 of 191 matches
Mail list logo
