: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Is it possible? the handbook implies not and I can't get it to
work, but i could be doing it wrong..
I get fbt traces listed for KLDs (I get new entries for each
load
: quoted-printable
Content-Disposition: inline
Is it possible? the handbook implies not and I can't get it to
work, but i could be doing it wrong..
I get fbt traces listed for KLDs (I get new entries for each load
of the KLD which seems like a potential problem) but I can't
specify
implies not and I can't get it to
work, but i could be doing it wrong..
I get fbt traces listed for KLDs (I get new entries for each load
of the KLD which seems like a potential problem) but I can't
specify an SDT_PROBE and have it work.
Can you show us some example code?
/* Recycle fbt
it wrong..
I get fbt traces listed for KLDs (I get new entries for each load of the
KLD which seems like a potential problem) but I can't specify an
SDT_PROBE and have it work.
Can you show us some example code?
In
http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/src/sys
Is it possible? the handbook implies not and I can't get it to work, but
i could be doing it wrong..
I get fbt traces listed for KLDs (I get new entries for each load of the
KLD which seems like a potential problem) but I can't specify an
SDT_PROBE and have it work.
--
Daniel O'Connor
It appears that the KLD build process is missing a ctfmerge at the end, and
this results in KLDs with incomplete CTF information.
Here is a patch that fixes this. I verified it on amd64 with various KLDs.
Before:
# ctfdump /boot/kernel/if_cxgb.ko | wc -l
2269
# ctfdump /boot/kernel/zfs.ko | wc
Hi,
I have a few third party KLDs on my system (nvidia, acpi_ppc, dell, if_ndis)
and it's quite annoying to have to rebuild them each kernel build, or
upgrade. I have thought about putting them in /boot/modules but I have had
this crash on my fairly often (esp since I am running -current
On Mon, Nov 29, 2004 at 10:54:26PM +1030, Daniel O'Connor wrote:
Hi,
I have a few third party KLDs on my system (nvidia, acpi_ppc, dell,
if_ndis)
and it's quite annoying to have to rebuild them each kernel build, or
upgrade. I have thought about putting them in /boot/modules but I have had
On Mon, 29 Nov 2004 23:08, Ruslan Ermilov wrote:
Note that (obviously) the ports need to be tweaked to install the driver
source and build infrastructure there, but that's not too hard (to do by
hand for now anyway). I have the 4 I mentioned building just fine with 5
minutes work.
Any
Can't you just add modules override with absolute path name?
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
On Tue, 30 Nov 2004 14:35, M. Warner Losh wrote:
Can't you just add modules override with absolute path name?
I don't think so, because..
On Mon, 29 Nov 2004 23:08, Ruslan Ermilov wrote:
Any chance you can use the recently added PORTS_MODULES knob to do what
you want?
Hmm.. I don't really
In message: [EMAIL PROTECTED]
Daniel O'Connor [EMAIL PROTECTED] writes:
: On Tue, 30 Nov 2004 14:35, M. Warner Losh wrote:
: Can't you just add modules override with absolute path name?
:
: I don't think so, because..
MODULES_OVERRIDE is different. It can take a list of paths to
On Tue, 30 Nov 2004 15:58, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Daniel O'Connor [EMAIL PROTECTED] writes:
: On Tue, 30 Nov 2004 14:35, M. Warner Losh wrote:
: Can't you just add modules override with absolute path name?
:
: I don't think so, because..
Can somebody explain to me how sysctls from klds are relocated?
For background, after the binutils upgrade in -stable, I'm unable to
load linux.ko on my desktop. The faulting address is always
0x9010102464c457f (oidp-oid_parent) and the pc is in
sysctl_find_oid_name().
The crash looks like
Hi Folks,
Hopefully a quick question.
Is there any reason to prefer KLD modules for drivers etc over static
linking? For example, KLDs are covenient, loading and unloading for
development but is it a case of using KLD modules for development then
building drivers statically into the kernel when
I use them - where possible - when i have the same kernel for different boxes
and i can configure the differences via klm's.
danny
Hi Folks,
Hopefully a quick question.
Is there any reason to prefer KLD modules for drivers etc over static
linking? For example, KLDs are covenient
and attach calls during the load for a PCI device. I have
looked in the /usr/src/sys/pci directory and haven't found any KLDs to use
as an example. What are the steps I need to take to handle a PCI device in
a KLD? Are there any examples I can look out?
Oh yeah, I am doing this for a FreeBSD 3
In message [EMAIL PROTECTED] "Chris Ptacek"
writes:
: I am working on a KLD for a PCI device. My problem is I can't find how to
: call the probe and attach calls during the load for a PCI device. I have
: looked in the /usr/src/sys/pci directory and haven't found any K
I am working on a KLD for a PCI device. My problem is I can't find how to
call the probe and attach calls during the load for a PCI device. I have
looked in the /usr/src/sys/pci directory and haven't found any KLDs to use
as an example. What are the steps I need to take to handle a PCI device
Mike Smith writes:
I expect as much, but when I tried to make an IPX KLD, it paniced the
system on unload. I will test the FFS KLD soon though.
Panic on unload usually means that the code in question isn't designed
to unload. 8)
Such code should return an error instead of allowing the
On Mon, 18 Oct 1999, Mike Smith wrote:
Is it possible to compile a kernel with no filesystems supported and have
the boot loader load FFS? I have built an FFS module but I have not yet
had time to test it. Frankly, I am kind of afraid to for fear of trashing
my system.
As
On Tue, 12 Oct 1999, Warner Losh wrote:
How does one tell ddb about dynamic modules? I've had a couple of
crashes in my code where I've needed symbols from things dynamically
loaded... Does gdb grok them any better?
I thought ddb was supposed to know about them already but perhaps that
How does one tell ddb about dynamic modules? I've had a couple of
crashes in my code where I've needed symbols from things dynamically
loaded... Does gdb grok them any better?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Slashdot, in a discussion regarding QNX, someone described it with the
following:
Under QNX, if your driver crashes, the kernel just restarts it.
After reading it, I became more interested in KLDs. My only prior
experiece was installing the Linux KLD and that was done
Could things be done in such a way that like QNX, it can
kill and restart a misbehaving driver? What other cool things can be
done?
QNX doesn't do that.
Actually, in many cases it does. There are numerous advantages in a
well-designed/optimized micro-kernel that FreeBSD will never
Could things be done in such a way that like QNX, it can
kill and restart a misbehaving driver? What other cool things can be
done?
QNX doesn't do that.
Actually, in many cases it does. There are numerous advantages in a
well-designed/optimized micro-kernel that FreeBSD will never
On Sun, 10 Oct 1999, Mike Smith wrote:
You should note that neither QNX nor FreeBSD exhibit the above
behaviour. KLD is a linker; it allows you to link more stuff into the
kernel after it's been started. It doesn't implement a coprocess model
of any sort.
Yes, I knew this for FreeBSD,
On Slashdot, ...
Under QNX, if your driver crashes, the kernel just restarts it.
That's not in the least bit how QNX works... oh well, it's slashdot.
Cheers,
Jerry Hicks
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body
On Sat, 9 Oct 1999, W Gerald Hicks wrote:
On Slashdot, ...
Under QNX, if your driver crashes, the kernel just restarts it.
That's not in the least bit how QNX works... oh well, it's slashdot.
I've noticed Slashdotters tend to be clueless.
It doesn't matter in this case, it is
On Slashdot, in a discussion regarding QNX, someone described it with the
following:
Under QNX, if your driver crashes, the kernel just restarts it.
After reading it, I became more interested in KLDs. My only prior
experiece was installing the Linux KLD and that was done by a port
Peter Wemm wrote:
Don't forget, there are zero or more modules per file. Which one gets the
arguments? Coda (for example) is structured so that it has two modules, one
device (codadev) and one vfs (coda).
It seems to me that the one who gets the arguments is the one who
searches for it.
"Daniel C. Sobral" wrote:
assuming we are making it at all, the less pain. It provides a way
of getting parameters that is compatible with what is already
possible with loader (ie, the module need not differentiate between
it's method of loading). The code is working and ready.
Actually...
On Tue, 3 Aug 1999, Peter Wemm wrote:
Don't forget, there are zero or more modules per file. Which one gets the
arguments? Coda (for example) is structured so that it has two modules, one
device (codadev) and one vfs (coda).
Yes, the naming 'module_get_file_argstr()' had the _file_ for
Juha Nurmela wrote:
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
Actually... Loader passes a string. It seems the kldcode is passing
argv[]. Juha, you sure you have they both working the same way (from
a module's perspective)?
It's splatted together, by just putting ' '
Daniel C. Sobral wrote:
assuming we are making it at all, the less pain. It provides a way
of getting parameters that is compatible with what is already
possible with loader (ie, the module need not differentiate between
it's method of loading). The code is working and ready.
Actually...
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
Actually... Loader passes a string. It seems the kldcode is passing
argv[]. Juha, you sure you have they both working the same way (from
a module's perspective)?
It's splatted together, by just putting ' ' between words,
somewhere in there. Search
Juha Nurmela wrote:
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
Actually... Loader passes a string. It seems the kldcode is passing
argv[]. Juha, you sure you have they both working the same way (from
a module's perspective)?
It's splatted together, by just putting ' ' between
Peter Wemm wrote:
Don't forget, there are zero or more modules per file. Which one gets the
arguments? Coda (for example) is structured so that it has two modules, one
device (codadev) and one vfs (coda).
It seems to me that the one who gets the arguments is the one who
searches for it.
Daniel C. Sobral wrote:
Peter Wemm wrote:
Don't forget, there are zero or more modules per file. Which one gets the
arguments? Coda (for example) is structured so that it has two modules, on
e
device (codadev) and one vfs (coda).
It seems to me that the one who gets the
On Tue, 3 Aug 1999, Peter Wemm wrote:
Don't forget, there are zero or more modules per file. Which one gets the
arguments? Coda (for example) is structured so that it has two modules, one
device (codadev) and one vfs (coda).
Yes, the naming 'module_get_file_argstr()' had the _file_ for
Juha Nurmela wrote:
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
Actually... Loader passes a string. It seems the kldcode is passing
argv[]. Juha, you sure you have they both working the same way (from
a module's perspective)?
It's splatted together, by just putting ' '
On Sun, 1 Aug 1999, Chris Costello wrote:
On Sun, Aug 01, 1999, Juha Nurmela wrote:
Sometimes it would be handy to pass a commandline
to a kld, preloaded modules already support
arguments. kldload(2) unfortunately has only
the pathname.ko argument.
Is this really a problem? Can
Warner Losh wrote:
In message [EMAIL PROTECTED] Juha
Nurmela writes:
: Yes, but (this might be a trademark ;) commonly the arguments would
: be used during the sysinit-attach, and at that time sysctl has not yet
: been able to change anything. Use of sysctl would require a sidestep
: from
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes:
: Modules are not just drivers. Forget about drivers, and try again.
: :-)
But the generic mechanism extends beyond just drivers :-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of
Warner Losh wrote:
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes:
: Modules are not just drivers. Forget about drivers, and try again.
: :-)
But the generic mechanism extends beyond just drivers :-)
Ah, I recall now. Something similar to the way X works, with all the
information
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
Warner Losh wrote:
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes:
: Modules are not just drivers. Forget about drivers, and try again.
: :-)
But the generic mechanism extends beyond just drivers :-)
Ah, I recall now.
On Sun, 1 Aug 1999, Chris Costello wrote:
On Sun, Aug 01, 1999, Juha Nurmela wrote:
Sometimes it would be handy to pass a commandline
to a kld, preloaded modules already support
arguments. kldload(2) unfortunately has only
the pathname.ko argument.
Is this really a problem? Can
Warner Losh wrote:
In message pine.bsf.4.05.9908020021290.9676-100...@pena.oh5nxo.ampr.org
Juha Nurmela writes:
: Yes, but (this might be a trademark ;) commonly the arguments would
: be used during the sysinit-attach, and at that time sysctl has not yet
: been able to change anything. Use
In message 37a5c680.3ca1d...@newsguy.com Daniel C. Sobral writes:
: Modules are not just drivers. Forget about drivers, and try again.
: :-)
But the generic mechanism extends beyond just drivers :-)
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in
Warner Losh wrote:
In message 37a5c680.3ca1d...@newsguy.com Daniel C. Sobral writes:
: Modules are not just drivers. Forget about drivers, and try again.
: :-)
But the generic mechanism extends beyond just drivers :-)
Ah, I recall now. Something similar to the way X works, with all the
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
Warner Losh wrote:
In message 37a5c680.3ca1d...@newsguy.com Daniel C. Sobral writes:
: Modules are not just drivers. Forget about drivers, and try again.
: :-)
But the generic mechanism extends beyond just drivers :-)
Ah, I recall now.
On Sun, Aug 01, 1999, Juha Nurmela wrote:
Hello.
Sometimes it would be handy to pass a commandline
to a kld, preloaded modules already support
arguments. kldload(2) unfortunately has only
the pathname.ko argument.
Is this really a problem? Can the administrator not use
sysctl
On Sun, 1 Aug 1999, Chris Costello wrote:
On Sun, Aug 01, 1999, Juha Nurmela wrote:
Sometimes it would be handy to pass a commandline
to a kld, preloaded modules already support
arguments. kldload(2) unfortunately has only
the pathname.ko argument.
Is this really a problem? Can
Hello.
Sometimes it would be handy to pass a commandline
to a kld, preloaded modules already support
arguments. kldload(2) unfortunately has only
the pathname.ko argument.
Following url proposes patches to make a new syscall
kldload(char *pathname, char **argv, struct kldload *)
and keep old
On Sun, Aug 01, 1999, Juha Nurmela wrote:
Hello.
Sometimes it would be handy to pass a commandline
to a kld, preloaded modules already support
arguments. kldload(2) unfortunately has only
the pathname.ko argument.
Is this really a problem? Can the administrator not use
sysctl
On Sun, 1 Aug 1999, Chris Costello wrote:
On Sun, Aug 01, 1999, Juha Nurmela wrote:
Sometimes it would be handy to pass a commandline
to a kld, preloaded modules already support
arguments. kldload(2) unfortunately has only
the pathname.ko argument.
Is this really a problem? Can
In message pine.bsf.4.05.9908020021290.9676-100...@pena.oh5nxo.ampr.org Juha
Nurmela writes:
: Yes, but (this might be a trademark ;) commonly the arguments would
: be used during the sysinit-attach, and at that time sysctl has not yet
: been able to change anything. Use of sysctl would require a
57 matches
Mail list logo
