Re: Crypto in the kernel: where how?
What is the plan (if any) for including crypto stuff in the kernel? As time goes on this will be more and more needed, eg. for IPSec and other VPN applications. The KAME/IPv6 guys have already brought this up; the agreement was that... I just prepared IPsec related patches which includes crypto directory, and did kernel build and make world check on my remote machine. But I can't do reboot check because of the wd0 issue. I have not yet succeeded in booting my local machine with ATA disk. My remote machine has only SCSI disks but I'm afraid to reboot it. And I wonder if I can send the patches to lists to solicite comments. By the way, all crypto stuff are put under the sys/crypto dir in the patch. Should some of them put under sys/libkern instead? Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where how?
...a sys/crypt/ directory should hold their DES code. :-) ^ Shouldn't this be crypto ? That is what I see if I look on internat in the /usr/local/etc/cvsup/sup directory. So it should, and in the patch that I have, it is :-). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
netnoot - INT 18 device
I got a new machine (500 MHz PIII) with a 12 GB disk (nothing nowadays though :-). There was already NT 4.0 installed and a 3.9 GB unitialized partition left. I booted the 3.3 CD, chose Custom and tried to create a FreeBSD partition. 13200 blocks were left. I tried both, half of it and the whole left partition but afterwards in the label editor there was no entry I could define my filesystems on. Weird. Maybe a problem with large disks? Maybe that the FreeBSD partition has to be in the first 2 GB of a disk? Maybe because I could not create FreeBSD slices? Maybe I should repartition the whole disk, install FreeBSD and then reinstall NT . Sigh. To avoid all this the following idea came to me: while studying the BIOS boot options I saw ATAPI IDE, FD, and Int 18 device. Does FreeBSD support Int 18 Device? I assume this could be something like netboot, couldn't it? OTOH, the PCI 100 MBit ethernet card has a EPROM socket on it... With a 100MBit network, diskless could become interesting and I could try to netboot this machine. Any suggestions? -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why VMIO directory is a bad idea?
On Fri, Dec 10, 1999 at 08:56:47AM -0500, Zhihui Zhang wrote: Can anyone give me an idea on how big a directory could be in some environment? Our inn's /news/spool/control/cancel directory is almost 300k. If we were a significantly larger news site we probably wouldn't be running inn though. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why VMIO directory is a bad idea?
On Fri, 10 Dec 1999, David Malone wrote: On Fri, Dec 10, 1999 at 08:56:47AM -0500, Zhihui Zhang wrote: Can anyone give me an idea on how big a directory could be in some environment? Our inn's /news/spool/control/cancel directory is almost 300k. If we were a significantly larger news site we probably wouldn't be running inn though. I use the CMU cyrus server to manage mail for my system, and also to handle mailing lists archives. I have an archive of the freebsd-current mailing list that contains around 33,000 messages, and with one file per message the directory size is about 530k. The big hit I see is Cyrus's use of dbm to manage index information, not the cost of directory operations. Typically, due to the way IMAP is usually used, no one reads in all the files, etc. However, performing an ls is non-trivially expensive: # time ls -af /dev/null 1.018u 0.241s 0:01.25 100.0%225+4365k 0+0io 0pf+0w 1.012u 0.288s 0:01.29 100.0%225+4352k 0+0io 0pf+0w 1.053u 0.280s 0:01.33 100.0%223+4273k 0+0io 0pf+0w 1.076u 0.253s 0:01.32 100.0%219+4238k 0+0io 0pf+0w 1.091u 0.235s 0:01.33 99.2% 224+4273k 0+0io 0pf+0w # ls -af | wc -l 33323 This is under 2.2-STABLE, although I hope to push it to a 3.3-STABLE machine in the near future. This machine is currently a 486 dx2 66 w/24 mb of ram. It will become a Pentium sometime soon, with more memory. It should be observed, for the benefit of critics, that storing a mailbox in this format is far better from a performance perspective than storing all the messages in a single file :-). But it goes through a bunch of inodes (it almost justifies the default inode allocate on large disks :-), and does have drawbacks in terms of directory size. Because messages are hardly ever removed from this directory, my guess is that it's use of the directory space is fairly compact and unfragmented. Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fw: Clustered Read/writes and NFS..
reposting to the hackers ;-) - Original Message - From: Robert Gordon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 09, 1999 1:56 PM Subject: Clustered Read/writes and NFS.. Hello, I'm attempting to understand if the NFS implementation takes advantage of clustered read/writes. So far I see that if NFS needs a buf that (via getnewbuf()) a call could be made to vfs_bio_awrite() which could cause a clustered write to free up some buffers... but I don't see that NFS takes advantage of a clustered read/write Thanks, Robert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Contribution
Hello, I originally posted this message to -questions mailing list, but it wasn't probably the right place :-( So, if you read it few days ago, please silently ignore ;-) I use FreeBSD on my home PC and one server. I must say, that I am *very* satisfied with it. a) I am maintainer/author of Filesystems-HOWTO. It's a document describing dozens of filesystems and accessing them from various OSes. I think it would be very useful to have this HOWTO in FreeBSD. What do you think? For more information see http://www.penguin.cz/~mhi/fs/. Should I make a port for you? b) I'd like to write in my HOWTO also about filesystems in FreeBSD. Can you help me? Any documents, links and other information are *very* welcome. I'd like to ask also BSD FFS developers. c) Few months ago I wrote BFS (UnixWare boot filesystem) Linux kernel implementation. Because [EMAIL PROTECTED] implemented better (read-write) version of it, my version is obsolete. If you want to port this code to FreeBSD, I can re-release it under BSD license. There is small problem - I've never developed anything to FreeBSD kernel. But I have kernel-level development experience. d) I installed FreeBSD on extended partition using GRUB bootmanager (see GNU homepage). Are you interested? [Some people asked me to write step-by-step howto. But it is not easy, so I'd like to make small changes to sysinstall to accept also extended FreeBSD partitions]. Thanks, Martin. PS: Please CC all replies also to me, because I have no time to read carefully hackers mailing list. -- [EMAIL PROTECTED] PGP: 1024/226C5935 2E A6 9F 01 D1 88 85 15 9B 08 12 34 4C 46 41 21 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fw: Clustered Read/writes and NFS..
:reposting to the hackers :;-) :- Original Message - :From: Robert Gordon [EMAIL PROTECTED] :To: [EMAIL PROTECTED] :Sent: Thursday, December 09, 1999 1:56 PM :Subject: Clustered Read/writes and NFS.. : : : Hello, : : I'm attempting to understand if the NFS implementation takes : advantage of clustered read/writes. So far I see that if NFS needs : a buf that (via getnewbuf()) a call could be made to vfs_bio_awrite() : which could cause a clustered write to free up some buffers... but I : don't see that NFS takes advantage of a clustered read/write : : Thanks, : Robert [EMAIL PROTECTED] Unfortunately there is no advantage to clustering NFS writes, because the NFS write packets are limited to the NFS write size which is usually 8K, so you still need to do separate RPCs. But there is an advantage to clustering NFS commits (essentially the write-verification part of an NFS write), and FreeBSD *does* do that. In fact, Alfred is working on a patch that will make the commit clustering even better. Under NFSv3 the NFS server may cluster NFS write packets it receives prior to writing the data to the physical media, and FreeBSD does do this. This is because NFSv3 writes are allowed to be asynchronous. NFSv2 writes are required to always be synchronous which prevents the server from clustering them when transfering the data to physical media. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why VMIO directory is a bad idea?
:(1) If the directory file is less than one page, there will be a waste of :memory due to internal fragmentation. Why do not we set a limit, say one :page, on when we start VMIO a directory? It is true that when we use VMIO to back directories that a minimum of one page of memory is used even for a small directory. However, unlike B_MALLOC space in the buffer cache the VM page cache is much better suited towards figuring out when cached VM pages can be reused. So even though there is waste the page may still be reused by the system fairly quickly if need be. When we use B_MALLOC space in the buffer to store a small directory 'efficiently', it tends to get reused too quickly due to the small size of the buffer cache which results in another physical I/O the next time the directory needs to be accessed. Given the choice being some wasteage (which is less then you think) and having to do another physical I/O, it is clear that the advantage is to keep the waste and avoid the physical I/O. :(2) If VMIO directory is not desirable for some reasons, how about bump up :the usecount of the buffer used by a directory file to let it stay in the :queue longer? This is how the old algorithm worked. It failed utterly to address the problem and in fact led to a considerable amount of complexity and wasted cpu cycles when the buffer cache became unbalanced (due to excessive write loading or directory scanning loading). :(3) Or maybe we can add a parameter to the filesytem, telling it to try to :preallocate some contiguous disk space for all directory files. I guess :that the cost per bit on disk is less than the cost per bit in memory. I believe the filesystem already does this. -Matt Matthew Dillon [EMAIL PROTECTED] :Can anyone give me an idea on how big a directory could be in some :environment? : :Any comments or ideas are appreciated. : :-Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Contribution
On Fri, 10 Dec 1999, Martin Hinner wrote: I originally posted this message to -questions mailing list, but it wasn't probably the right place :-( So, if you read it few days ago, please silently ignore ;-) I use FreeBSD on my home PC and one server. I must say, that I am *very* satisfied with it. a) I am maintainer/author of Filesystems-HOWTO. It's a document describing dozens of filesystems and accessing them from various OSes. I think it would be very useful to have this HOWTO in FreeBSD. What do you think? For more information see http://www.penguin.cz/~mhi/fs/. Should I make a port for you? I've found it's better to not ask and just do it, unless it's something controversial. Otherwise you'll get the resounding approval of silence. :) b) I'd like to write in my HOWTO also about filesystems in FreeBSD. Can you help me? Any documents, links and other information are *very* welcome. I'd like to ask also BSD FFS developers. As you probably know, docs are sparse; the code is sometimes the best doc. c) Few months ago I wrote BFS (UnixWare boot filesystem) Linux kernel implementation. Because [EMAIL PROTECTED] implemented better (read-write) version of it, my version is obsolete. If you want to port this code to FreeBSD, I can re-release it under BSD license. There is small problem - I've never developed anything to FreeBSD kernel. But I have kernel-level development experience. The filesystem layer isn't one of the easier parts of the system to work with, but since you're the writing type, document your attempt. d) I installed FreeBSD on extended partition using GRUB bootmanager (see GNU homepage). Are you interested? [Some people asked me to write step-by-step howto. But it is not easy, so I'd like to make small changes to sysinstall to accept also extended FreeBSD partitions]. Don't ask, just do it! :) Provide patches! Patches speak louder than words. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
AWE64 and 4.0
Pardon me if this was sent to the wrong list, but -hackers seemed as good a place as any... I'm running FreeBSD4.0, current as of 12/10/99 (today)...I just traded with a friend and found myself with an SB AWE 64...while there are instructions on getting this card working under 3.2, there are none for 4.0 - in which the kernel config pnp syntax has totally changed. Even if it hadn't, my kernel still doesn't recognize it...if there's anyone out there that has any information, please, let me know. Thanks, Rob -- [EMAIL PROTECTED] http://ota.pernet.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where how?
| US sites mirror their crypto from freebsd.org, international ones from the | international repository. The preferred path is for code to be committed | by international people to the international repository, since it can be | imported from there back into the US - if we can avoid it we shouldn't | commit stuff to the US repository on its own since that prevents most of | our users (by geography) from accessing it. However at least in the case | of OpenSSL (which I'm planning to import into internat when I go home to | australia next week :-) the two will have to be divergent due to the | patent restrictions on RSA. The RSA patent makes things a lot more difficult. If we do add some crypto into the kernel I suggest we use patent-free algorithms to start with. -- Dan Moschuk ([EMAIL PROTECTED]) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where how?
On Fri, 10 Dec 1999, Dan Moschuk wrote: | our users (by geography) from accessing it. However at least in the case | of OpenSSL (which I'm planning to import into internat when I go home to | australia next week :-) the two will have to be divergent due to the | patent restrictions on RSA. The RSA patent makes things a lot more difficult. If we do add some crypto into the kernel I suggest we use patent-free algorithms to start with. This was actually part of an unrelated point I was making - RSA will definitely not be going into the kernel anywhere at this point! In general, we want the two crypto repositories to stay in sync which generally means propagating from internat - freefall, but we can't do it for RSA. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why VMIO directory is a bad idea?
:(3) Or maybe we can add a parameter to the filesytem, telling it to try to :preallocate some contiguous disk space for all directory files. I guess :that the cost per bit on disk is less than the cost per bit in memory. I believe the filesystem already does this. The FFS tries to allocate space contiguously for any type of file. It does not PRE-allocate disk space, which will result wasteage of disk space if that space is not used later. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AWE64 and 4.0
try this: device pcm0 device sbc0 IIRC pnp is standard in the latest -current, so if yours is more than a few days old you may need controller pnp0 too. If the above doesnt work, try options PNPBIOS. And for further reference, the freebsd-multimedia list would be your best bet. On Fri, 10 Dec 1999, Rob King wrote: Pardon me if this was sent to the wrong list, but -hackers seemed as good a place as any... I'm running FreeBSD4.0, current as of 12/10/99 (today)...I just traded with a friend and found myself with an SB AWE 64...while there are instructions on getting this card working under 3.2, there are none for 4.0 - in which the kernel config pnp syntax has totally changed. Even if it hadn't, my kernel still doesn't recognize it...if there's anyone out there that has any information, please, let me know. Thanks, Rob -- [EMAIL PROTECTED] http://ota.pernet.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where how?
| This was actually part of an unrelated point I was making - RSA will | definitely not be going into the kernel anywhere at this point! In | general, we want the two crypto repositories to stay in sync which | generally means propagating from internat - freefall, but we can't do it | for RSA. Indeed. So, the crypto stuff stays on internat and is then imported to freefall? How does that affect our mirror sites? Are we not then exporting it out to the world from freefall, or is the crypto stuff snagged from internat as well? I would much rather see freefall move a few thousand miles north! :-) -- Dan Moschuk ([EMAIL PROTECTED]) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Device driver - panics executing kvtop() when compiled as KLD module
I am in the process of writing a device driver for the Turtle Beach Multisound
Monterey soundcard. At the moment I am statically compiling my code into the
kernel and it is somewhat operational. I have added conditional compilation
code to also compile as a kld module. My problem is that when I kldload my
module the machine panics in a subfunction of my attach() function that makes
a call on kvtop() I drop into the debugger DDB and the instruction pointer is
in the middle of the kvtop() function. If I disable my attach function the
module will load and unload, but it is nonfunctional without the attach()
being executed. Statically compiled into the kernel kvtop() executes with no
problem.
To be succinct can I use kvtop() in code that is a kld module?
If not, what is the alternative to accomplish the same result?
For those interested and/or willing to help more details follow, others can
move on.
The panic info is
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xbfc00340
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01c98d9
stack pointer = 0x10:0xc2cdbe70
frame pointer = 0x10:0xc2cdbe70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor flags = interrupt enabled, resume, IOPL=0
current process = 250 (kldload)
interrupt mask =
kernel type 12 trap, code = 0
Stopped at kvtop+0x2d: movl PTmap(,%eax,4),%edx
db show registers
cs0x8008
ds 0x10
es 0x10
ss 0x10
eax 0xd0
ecx 0xd This is the physical address I want
edx0
ebx 0xc0570a00
esp 0xc2cdbe70
ebp 0xc2cdbe70
esi 0xc0577100
edi0
eip 0xc01c98d9 kvtop+0x2d
efl 0x10212 end+0xb00e
The TurtleBeach hardware demands that the driver has access to a 0x8000 (32K)
byte contiguous chunk of physical memory in the ISA hole and more specifically
it must start at one of the following locations
B || C8000 || D || D8000 || E || E8000
The line of my code that causes the panic as a module is
switch (kvtop(msd-dev-id_maddr)) {
...
}
dev is a pointer to struct isa_device and id_maddr is 0xd because my kernel
config definition for this device is
device msm0at isa? port 0x290 irq 10 tty iomem 0xd iosiz 0x8000
Which by some magic gets generated into ioconf.c in my kernel compile directory
as
struct isa_device isa_devtab_tty[] = {
. other tty drivers omitted .
{ 18, msmdriver, 0x0290, IRQ10, -1, C 0xD, 32768, 0, 0, 0x, 0
,0, 0, 0, 1, 0, 0 },
0};
My code to compile as a module must provide this information to the system as
part of the module load. My conditional code as a module is as follows.
static void
msm_drvinit(void *unused)
{
dev_t dev;
dev = makedev(CDEV_MAJOR, 0);
cdevsw_add(dev, msm_cdevsw, NULL);
}
#ifndef MSM_MODULE
SYSINIT(msmdev, SI_SUB_DRIVERS, SI_ORDER_MIDDLE+CDEV_MAJOR,
msm_drvinit, NULL)
#else /* MSM_MODULE */
/*
* Here is the support for if we ARE a kld module
*/
#include sys/module.h
/*
* XXX Hardwiring this stuff is not wise, need to find some other
* mechanism to specify this stuff
*/
static struct isa_device isadev = {0, msmdriver, 0x290, IRQ10, -1, (caddr_t) 0x
D, 0x8000, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0};
static int msmm_event (module_t, modeventtype_t, void *);
static int
msmm_event (module_t mod, modeventtype_t cmd, void *arg)
{
int rv = 0;
switch (cmd) {
case MOD_LOAD:
msm_drvinit(arg);
if (msmprobe(isadev) ) {
msmattach(isadev);
} else {
printf("msm driver: probe failed\n");
cdevsw[CDEV_MAJOR] = NULL; /* detach from cdevsw[] */
rv = 1;
}
break;
case MOD_UNLOAD:
if (sca[isadev.id_unit] != NULL)
/* malloc in msmattach */
free(sca[isadev.id_unit], M_DEVBUF);
/* deallocate buffers, MS_dev_t */
else
printf("unload-msm0\n");
break;
default:
rv = EINVAL;
break;
}
return rv;
}
/* This declares the kld module to the system MACRO in /sys/conf.h
* I expanded this macro manually because the compiler was howling about the
* msmm_event element structure initializer until I threw the cast on it.
* I don't think this has anything to do with the problem I am having.
* CDEV_MAJOR = 30 for soundcard drivers
* CDEV_MODULE(msmm, CDEV_MAJOR, msm_cdevsw, msmm_event, 0);
*/
static struct cdevsw_module_data msmm_cdevsw_mod = {
(modeventhand_t)msmm_event ,
0 ,
30 == NODEV ? NODEV : makedev( 30 , 0),
msm_cdevsw
};
static moduledata_t msmm_mod = {
"msmm",
Re: Interrupt handler for PCI
This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED] Be sure to reply to that address. Hello, I'm writting driver for PCI board. Is't possible to set interrupt handler for PCI device not in attach function? If yes, how? For ISA is possible to do by calling reconfig_isadev(dev, imask) for one device. That's the hard way of doing it. Much better just to register one interrupt handler and then vector inside that handler to the correct local function. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: netnoot - INT 18 device
I got a new machine (500 MHz PIII) with a 12 GB disk (nothing nowadays though :-). There was already NT 4.0 installed and a 3.9 GB unitialized partition left. I booted the 3.3 CD, chose Custom and tried to create a FreeBSD partition. 13200 blocks were left. I tried both, half of it and the whole left partition but afterwards in the label editor there was no entry I could define my filesystems on. Weird. Some more details here would really help. Lots more details, like the exact size of the NT partition, which entry it occupied in the slice table, the various disk geometries in play (BIOS, NT, FreeBSD). The system boot messages from FreeBSD, the output with debugging enabled, the output in Wizard mode in the slice editor. Without these it's too hard to even begin to guess what's going on. Maybe a problem with large disks? Not AFAIK. Maybe that the FreeBSD partition has to be in the first 2 GB of a disk? Nope, modulo some booting issues on some broken BIOSsen. Maybe because I could not create FreeBSD slices? Er, if you don't create a slice, of course you can't create any partitions. while studying the BIOS boot options I saw ATAPI IDE, FD, and Int 18 device. Does FreeBSD support Int 18 Device? No. I assume this could be something like netboot, couldn't it? It could be. OTOH, the PCI 100 MBit ethernet card has a EPROM socket on it... With a 100MBit network, diskless could become interesting and I could try to netboot this machine. Not until we complete the software support for it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
large file aware utilities
Greetings, it appears that tail is not functioning properly with a file 2 GB. What can I do to tail such a file (actually to make it smaller than 2 GB) ? Is there a large file capable tail for FreeBSD ? I have also found that 'less' is unable to display that file, but more is. :-/ Michael To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Device driver - panics executing kvtop() when compiled as KLD module
I am in the process of writing a device driver for the Turtle Beach Multisound
Monterey soundcard. At the moment I am statically compiling my code into the
kernel and it is somewhat operational. I have added conditional compilation
code to also compile as a kld module. My problem is that when I kldload my
module the machine panics in a subfunction of my attach() function that makes
a call on kvtop() I drop into the debugger DDB and the instruction pointer is
in the middle of the kvtop() function. If I disable my attach function the
module will load and unload, but it is nonfunctional without the attach()
being executed. Statically compiled into the kernel kvtop() executes with no
problem.
To be succinct can I use kvtop() in code that is a kld module?
Yes, althought it's not the right way to do this.
If not, what is the alternative to accomplish the same result?
You should be using the bus_space functionality to hide the mapping.
switch (kvtop(msd-dev-id_maddr)) {
Er. You do understand that kvtop() attempts to return a physical address
when given a kernel virtual address, right? The isa_device id_maddr
field is a physical address, for which you want a mapping in kernel
virtual space.
Assuming you don't want to do this properly and use bus_space, you need
to use pmap_mapdev(), or to take advantage of the fact that the ISA hole
is already mapped into kernel virtual space.
You can convert a physical address in the ISA hole to a virtual address
in kernel space with:
#include pmap.h
#include machine/md_var.h
...
vaddr = (paddr - ISA_HOLE_START) + atdevbase;
Note that this approach is somewhat frowned upon, and if you're working
with -current it is very definitely the wrong way to do it, but for an
expedient solution it'll do the job.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Use of the ppi interface
- please only post to one list - please do not post HTML messages to public mailing lists I'm using the parallel port to control some sort of a hardware (i2c). You should probably use the i2cbb driver for this, as it can be easily tweaked to do what you're trying to do here. For that I generate pulses using the ppi device (geek port). The problem is that in some cases, the pulse isn't generated. What I do is sending an ioctl to make the device high (1) and another ioctl to set the device low (0). It seems that in some cases, the two commands arrive together to the device so the pulse isn't wide enough. The timing of the output transitions under ppi are very dependant on what the rest of the system is doing. It's not really suitable for this application as-is; you would be better off either using the 'lpbb' driver or building an external parallel-to-i2c interface adapter. Does the ppbus layer stores the ioctl's in some sort of a buffer and than flushes its content to the hardware? No. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
