Re: precise timing
[...] was suggested you may want to consider a dedicated cpu based controller. Thre are a number of solutions for hobbyists (such as the handyboard, see www.handyboard.com). Unfortunately, money is a big factor. So that's not an option. :/ Atmel AVR microcontrollers are $10 from distributors like Digikey (and Digikey usually has high prices). They're very slick and VERY FAST. You can do 12 MIPS with one of their chips. Of course you'd need to spend some time learning their instruction sets/learning how to code in C for them. There is a C compiler in the ports named avr-gcc to do just that. As for programmers, you can program these chips with a simple homebrew cable that plugs into your parallel port. Please see: http://www.bsdhome.com/avrprog Is that cheap enough? -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_strip for FreeBSD?
On Tuesday 14 August 2001 10:27, Warner Losh wrote: In message [EMAIL PROTECTED] David Scheidt writes: : :I was thinking about porting netbsd's if_strip driver (the driver for : : the metricom ricochet radios--allows you to use these radios as nodes : : in a WLAN). Before I do this, I thought I should first check to see if : : anyone else had already ported it to FreeBSD...? : : Are these useful now that metricom has shut down? Some versions of the metricom modems would allow point to point communications when they weren't on the merticom net. I don't know if this driver is for one of these or not, but it might not be a bad thing to do if so. I'll be there will be a lot of cheap modems on the market soon. Sierra evidentally got stiffed for $10M in inventory of these modems. They should be appearing on the surplus market soon... Exactly. This is the reason for my interest. I have a couple of the new 128Kbs radios (the ricochet GS and GT models) and they have a different MAC address format then the older radios that the if_strip driver was originally written for. The difference is only this: Older radio MAC format: - Newer radio MAC format: XX-- or XXX-- So in addition to porting the basic driver to freebsd, it would be smart to add code to accommodate the newer radios. Oh, and the new radios work in peer-to-peer mode just fine. You can either use them like regular modems and just dial the MAC address of the other modem and establish a ppp link, or they can be used in Starmode (which is what if_strip is for), allowing you to use them like wireless ethernet cards. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_strip for FreeBSD?
On Tuesday 14 August 2001 11:39, Warner Losh wrote: In message [EMAIL PROTECTED] Devin Butterfield writes: : Oh, and the new radios work in peer-to-peer mode just fine. You can : either use them like regular modems and just dial the MAC address of the : other modem and establish a ppp link, or they can be used in Starmode : (which is what if_strip is for), allowing you to use them like wireless : ethernet cards. Cool what frequency do the new cards operate at? 902-928MHz. They are Frequency hopping spread spectrum radios, and I think they can do 1 watt max. I've found that I can maintain a link at about 2 blocks away with ping times around 180-200ms (using PPP). I'm sure I could probably get even better range if there weren't any houses or trees in the way. :) -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
if_strip for FreeBSD?
Hi folks, I was thinking about porting netbsd's if_strip driver (the driver for the metricom ricochet radios--allows you to use these radios as nodes in a WLAN). Before I do this, I thought I should first check to see if anyone else had already ported it to FreeBSD...? -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SmartDisk USB CompactFlash reader
On Tuesday 24 July 2001 9:37, Jim Bryant wrote: Alfred Perlstein wrote: * Leif Neland [EMAIL PROTECTED] [010724 19:18] wrote: I've got such a device; it was nessecary, because my camera run out of batteries before I could retrieve 48MB of pictures over the normal serial port When I plug it in it displays: ugen0: SmartDisk Corp. SM/CF Combo USB Reader, rev 1.00/0.83, addr 2 Can this be read in FreeBSD? Try compiling in the 'umass' driver, you may be out of luck, SanDisk produced a version of thier reader that didn't use the USB disk specification and requires a proprietary driver for it, you may be stuck using this from windows. Good news is that you can get one that works in freebsd for only about 20$. I've been interested in this too... Which one is known to work under FreeBSD? I'm using the Sandisk Imagemate SDDR-31. Works fine here. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD for ARM processor
On Tuesday 24 July 2001 7:59, David O'Brien wrote: On Tue, Jul 24, 2001 at 11:49:16AM -0500, Dave Feustel wrote: Strongarm-based pcs designed by Chalice Technologies http://www.chaltech.com are available from Simtek http://www.simtec.co.uk/ This brings up the issue of reference platform for the StrongARM port. There is no one clear choice as there is for the PowerPC. Realistically, we probably need to pick an easily obtainable consumer StrongARM product. The Compaq iPaq comes to mind. However, it is not development-friendly at the moment as it does not have peripherals such as built-in NIC, hard drive, or serial console capabilities. The ipaqs do have a serial port. I've been playing with linux on mine for a while now and I frequently use the serial console. Some good points about the ipaq are that it is readily available, most all the hardware specs are available from the CRL (Compaq's Cambridge Research Lab) folks at handhelds.org, and of course the coolness factor. :) -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Thursday 14 June 2001 9:13, Alfred Perlstein wrote: * Rajappa Iyer [EMAIL PROTECTED] [010614 22:23] wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Because they did benchmarks on systems without tuning. So why doesn't FreeBSD ship with a tuned configuration? Just curious... -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: LCD driver port (Linux - FreeBSD) needed for car-mp3 player
On Sunday 29 April 2001 11:51, Shaun Dwyer wrote: Hi Mike, The software I am using in Linux (cajun - cajun.sourceforge.net) requires a serial display to work. What the linux driver does is emulate the serial display, and provides a /dev/lcd. As I am not a perl coder, I cannot modify Cajun to use the app you wrote, And as I am not a C coder, I cannot modify what you wrote to behave like the linux driver. Unless there is something already around that can take input in the way /dev/cuaaX does, and then pump the data into what you wrote, I think that the easiest way to do this is to make a driver for FreeBSD that behaves exactly the way that the Linux driver does. Writing a driver is not the easiest way to go and if you don't know C then you can't write the driver. I think what your getting at (IIRC from your original post) is that you are asking someone to volunteer to write it for you. This is not a small request as writing kernel drivers is not a trivial task, can be very time consuming, and most people don't have time. Anyway, this looks like a pretty cool project and hopefully someone with some extra time on their hands will take up the task. Alternatively, you could learn C, learn how to write FreeBSD device drivers by reading the source code of existing drivers, and then write it yourself. :) I'm sure folks on this list (including myself) would be willing to answer any questions you had. Good luck! -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Porting a Linux driver to FreeBSD with ioctl return values
On Monday 26 March 2001 11:24, Alfred Perlstein wrote: * Coleman Kane [EMAIL PROTECTED] [010326 22:40] wrote: Yeah, that's basically what I had to do in tdfx. You can take a look int src/sys/dev/tdfx/tdfx_pci.c under tdfx_ioctl(...) to get an idea of what needs to be done, if you need more info. Tdfx basically implements the API from device_3dfx in Linux. Is there anyone we can PLEAD with to explain that to the linnux people that that's a broken way to implement ioctl()? I did the original port of the linux telephony driver that Roger Hardiman has been kind enough to volunteer taking up maintainership of, and I butted heads with this problem (and the people who were perpetuating it) I can assure you. The author of the linux driver agreed that it wasn't the right way to do it, and I managed to convince him that it needed to be changed, but Alan Cox refused to accept any changes to the linux telephony API (regardless of the fact that it was "broken"). The fear was that it would break existing applications which depended on this ioctl hack. And so the breakage is perpetuated, on and on... -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing latency
On Monday 19 March 2001 4:36, Will Andrews wrote: On Mon, Mar 19, 2001 at 07:46:53PM -0500, Dennis wrote: I never got an answer (as usual) from bill paul when I made the suggestions, and noone seemed interested in getting it fixed. He seems to get insulted when I infer that he did something wrong. It's like they say: "money talks". Similarly, "patches talk". Suggestions don't really do that. I'm not defending Dennis here, but this statement infers that nothing gets done unless maintainers are a) paid or b) someone else does the work for them. I certainly hope this is not the case. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
David O'Brien wrote: On Mon, Dec 18, 2000 at 03:12:35PM -0600, Michael C . Wu wrote: I would be quite interested. But do we have the resouces and the man-hours to handle IA-64/KA-64/PPC/Alpha/StrongARM at the same time? Agreed. Perhaps the first step would be to start a [EMAIL PROTECTED] mailing list? Then why start Yet Another(tm) mailing list for it as everyone has agreed it isn't time for that yet. I don't think that "everyone" had reached any such agreement. It would seem to me that there is sufficient interest in FreeBSD/StrongARM that such a project is certainly worth pursuing. A mailing list would definitely be helpful to coordinating the project, gaining additional support for the project, and it would also serve to keep all the chatter off of -hackers. We could simply build a cross-gcc on ARM/Linux and the rest is making sure that everything compiles. How about concentrating effort on just _one_ new platform (ok, two -- ia64 and powerpc)??? Well I certainly would agree that we should concentrate effort on just one or two new platforms. If there is more interest in a PPC or ia64 port than in a StrongARM port, then it would make more sense to concentrate on those. However, if there is more interest in StrongARM now, and hence people willing to working on it *now* and bring it to life, then pursuing a StrongARM port would make more sense. I for one am interested in helping put FreeBSD on a StrongARM. :) -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
"Michael C . Wu" wrote: [sent to -small too] I would be quite interested. But do we have the resouces and the man-hours to handle IA-64/KA-64/PPC/Alpha/StrongARM at the same time? I am very interested in the PPC and StrongARM port, but there are so few of us on -ppc... Perhaps the first step would be to start a [EMAIL PROTECTED] mailing list? It would seem to me that the logical approach would be to pursue the project for which there is the most interest; for which there are people interested in working on it. A mailing list certainly seems like a good way to get started. I for one am interested in the StrongARM port. Of course, I have an iPAQ not a PPC so there lies the source of my bias. :) However, imho we should finish the FreeBSD/PPC project first. The StrongARM is quite similiar to the PPC processors. If we get the loader and init working, the rest will be a breeze. We could simply build a cross-gcc on ARM/Linux and the rest is making sure that everything compiles. Intel recently supplied me with the Brutus, Assabet, and the EBSA boards in addition to a compiler/debugger suite for a research project. I'd be willing to use my iPAQ as a guinea pig. ;-) The most important decision now would be: Should we concentrate on the PPC port first? Or should we go at each port simultaneously? Well, if there are enough people with PCC's that are interested in helping with the effort then perhaps pursuing the PPC port first would make more sense. I don't have a PPC so I couldn't help out there... If the decision is to pursue a StrongARM port then you can count me in. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
David Preece wrote: At 13:02 17/12/00 +, you wrote: Does anyone have any good tips to get started / HowTo's, or some simple examples that will give me knowledge like the PC Speaker or something simple like that? This is turning into a FAQ, but don't worry about it. The usual answer is to take one of the existing drivers and work out what it does. There's also a script for making shell drivers under /usr/share/examples/drivers. As for things like "how does DMA work?", "what exactly is an interrupt and what do I do with it?" or "what's the story with memory ranges and devices then?" then I'm afraid I can't help you there. In fact (to -hackers) this strikes me as one of the more fundamental problems of free software: I would go and write/fix some device drivers (for example the unknown phy in fxp that bothers me so much), except I can't really get a handle on how you're supposed to start on these things. Comments? URL's for IRQ101? Perhaps I should just stop whingeing and go hack with it to see what happens? (probably best). Jamie Dave I've had to deal with this frustration too (and I still do) because there is no good documentation to speak of for writing FreeBSD device drivers. It wouldn't be so bad if there were man pages for many of the commonly used functions like rman_get_bustag(), etc. This way you could study the code of other drivers and quickly be able to identify and understand the function calls you were seeing. Instead of grumbling "what the !@#$ does that function call do?" just type "man 9 foo" or whatever. This is IMHO one of the advantages linux has over FreeBSD. You can run by your local Barnes Noble bookstore and pick up a copy of "Linux Device Drivers" and start writing code that you actually understand. GRIPE You'd think a couple of these FreeBSD wizards would get together and write "FreeBSD Device Drivers" to spare us the pain and make a little $$ while they're at it! /GRIPE Just my 2 cents. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
StrongARM support?
Hi all, Is there any work in progress to support running FreeBSD on ARM processors? If not, are there any plans to? I would be very interested in helping out with such an effort. I would love to have FreeBSD running on my iPAQ PocketPC. :) I know that linux is already running well on ARM but I would really like to see FreeBSD running in its place. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
Jordan Hubbard wrote: Is there any work in progress to support running FreeBSD on ARM processors? If not, are there any plans to? I would be very interested in helping out with such an effort. I would love to have FreeBSD running on my iPAQ PocketPC. :) No work in progress, no plans. Would you be interested in heading such a project? That's what's needed. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Unfortunately, I don't think that I have enough knowledge to "head" such a project. I can certainly help in the effort though. I'm familiar with the FreeBSD kernel and have written drivers but I really know little about ARM or what it would take to get the FreeBSD kernel to boot on an ARM. I guess we could start by using the data collected by the NetBSD group's effort to run on ARM. Is there anyone here who is familiar with NetBSD's ARM project? Anyone here interested in such a project (and perhaps who has some prior knowledge of what would be involved in realizing such a beast)? -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Panics from trying to open dev after kldunload
Hi all, I'm working on a device driver for FreeBSD for a VoIP telephony card and I stumbled upon a serious problem. If I "kldunload" my driver and subsequently try to open the device, the kernel panics. I found that the vn device suffers from this same bug. For example: Before kldload vn: [root@dbm]# echo -n/dev/vn0 su: /dev/vn0: Device not configured [root@dbm]# This of course is the expected behavior. We then can do this... [root@dbm]# kldload vn [root@dbm]# echo -n/dev/vn0 [root@dbm]# Again, expected behavior... But if we then do this... [root@dbm]# kldunload vn [root@dbm]# echo -n/dev/vn0 we get an instant panic. It seems that there is already a pr open for this (kern/18270) which includes a patch to correctly cleanup after "kldunload". Is this the correct fix for this...why hasn't this been committed?? -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
/usr/include/sys/opt_posix.h missing...?
Hi, In trying to compile driver code which includes unistd.h, the compiler complains: cc -D_KERNEL -Wall -O2 -I/usr/include -o ixj.o -c ixj.c In file included from /usr/include/sys/unistd.h:40, from /usr/include/unistd.h:42, from ixj.c:21: /usr/include/sys/_posix.h:45: opt_posix.h: No such file or directory Sure enough...it isn't there!! Is this breakage? Who needs to be notified regarding this? By the way, this is on: FreeBSD dbm.wireless.net 4.1-STABLE FreeBSD 4.1-STABLE #17: Sun Aug 13 03:19:21 -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /usr/include/sys/opt_posix.h missing...?
Warner Losh wrote: In message [EMAIL PROTECTED] Devin Butterfield writes: : In trying to compile driver code which includes unistd.h, the compiler : complains: #include unistd.h isn't supported for drivers. You should not be including the -I/usr/include on the command line to compile the driver. If you are building a module, you should be using the bsd.kmod.mk framework to build the modules. include sys/unistd.h instead. You will also need to create an opt_posix.h in your driver's Makefile: KMOD=ifx SRCS=ifx.c device_if.h bus_if.h opt_posix.h .include bsd.kmod.mk should be all you need. You may also need to define SYSDIR as well if you don't have it installed in /usr/src/sys. You're right. I normally always do this as a module but was experimenting with some other code not using an appropriate Makefile. I still wonder why unistd.h (assuming it is not supported for drivers) would make any reference to a file that does not exist where it was looking? Nevertheless, thanks again for your help. All is fine now...:-) -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Unknown driver gobbles resources??
Hi all, In the process of learning device driver writing, I have written a simple skeleton driver for an isa PnP card I have. Thanks to some kind folks on the list I have ironed out most of my confusion. However I've run into a strange problem that has me stumped. Although this driver works (successfully probes, attaches, and gets it's needed io resources) when compiled into the kernel, if I compile it as a loadable module it fails to get it's io resources when loaded, and if I try to then unload it, the kernel panics (as the driver trys to release resources that were never allocated). I found that if I remove the "unknown" driver in isa_common.c with #if 0...#endif, my driver will load just fine! So my question is this: Do I need to do anything special to recover the resources from the unknown driver so that during loading *my* module can get the resources it needs?? Do I need to add something to my identify, probe, or attach routines to make this work right? Thanks again. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unknown driver gobbles resources??
Warner Losh wrote: In message [EMAIL PROTECTED] Devin Butterfield writes: : So my question is this: Do I need to do anything special to recover the : resources from the unknown driver so that during loading *my* module can : get the resources it needs?? Do I need to add something to my identify, : probe, or attach routines to make this work right? With modern enough versions of -current, you shouldn't have to do anything at all to make this work. It should just happen. And you'll likely not need an identify routine. The Unknown device just sucks up the plug and play resources. Therefore, there's already a device node in the tree addociated with that plug and play hardware, so your probe routine will just be called. However, this is fairly recent (like on the order of the first part of July, 2000). Before that you did ineed have to jump though many many hoops to make this work. Hare there any plans to "back-port" this to -STABLE? Or do we have to wait for 5.0? -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need help with driver....(long)
Mike Smith wrote:
I'm a newbie to device driver writing and I have been learning well by
reading the code of the other drivers in the system. I would ultimately
like to port a linux driver for a VoIP telephony card (Quicknet
PhoneJack) to FreeBSD, and so far I have a skeleton driver which does
successfully probe the card.
It does? How? Is this a PnP card?
Yes, it is a PnP card.
MAKEDEV is a script which does not interact with the kernel in any way.
You need to explicitly update MAKEDEV to know about your device.
Ok, thanks for clearing that up. :)
Where are you initialising these fields in the softc? (I assume, in your
probe, correct?)
Well, I think I'm initializing it correctly...see below.
You should check the return values from bus_alloc_resource and make_dev,
both of which you need to save in the softc so that you can detach
correctly.
Ok, I'll try this...
One thing I did try, was to write a very simple program to open the
device (now that I have correctly created the node in /dev) and I
inserted a printf in my ixj_open() in the driver to indicate that it
entered the open function...and this does seem to work. If open
succeeds, can I safely conclude that I'm doing things right?
On another note, I also compiled my skeleton driver as a module and it
loads ok, but if I try to use my little program to open the device, it
fails. I then tried inserting printf's in the probe and attach
functions, but when I load the module I still don't get any output. It
doesn't seem the driver probes or attaches if I load it as a module.
What am I doing wrong?
Below is the skeleton driver. I apologize if posting the entire thing
was inappropriate, but this way you guys can see exactly what I'm doing,
and more specifically, what I'm doing wrong. ;)
Thanks again.
--
Regards, Devin.
#include sys/types.h
#include sys/param.h
#include sys/systm.h
#include sys/malloc.h
#include sys/conf.h
#include sys/kernel.h
#include sys/module.h
#include sys/uio.h
#include sys/bus.h
#include machine/bus.h
#include machine/resource.h
#include sys/rman.h
#include isa/isavar.h /* more ISA stuff...*/
struct ixj_softc { /* param struct per a dev. */
dev_t dev;
int port_rid; /* resource id for port range */
int port_used; /* nonzero if ports used*/
struct resource* port_res; /* resource for port range */
};
/* Function prototypes */
static devclass_t ixj_isa_devclass;
static int ixj_isa_probe(device_t dev);
static int ixj_isa_attach(device_t dev);
static int ixj_isa_detach(device_t dev);
static d_open_tixj_open;
static d_close_t ixj_close;
static d_read_tixj_read;
static d_write_t ixj_write;
static d_ioctl_t ixj_ioctl;
#define CDEV_MAJOR 100
#define NIXJ16
static struct cdevsw ixj_cdevsw = {
ixj_open, /* open */
ixj_close, /* close*/
ixj_read, /* read */
ixj_write, /* write*/
ixj_ioctl, /* ioctl*/
nopoll,
nommap,
nostrategy,
"ixj", /* name */
CDEV_MAJOR, /* major*/
nodump,
nopsize,
0,
-1 /* bmaj */
};
/* Possible Vendor ID's */
/* add ID's for all cards here
*/
static struct isa_pnp_id ixj_ids[] = {
{ 0x10048946, "QTI0400 Internet PhoneJack" }, /* QTI0400 */
{ 0,NULL }
};
static int
ixj_isa_probe(device_t dev) /* isapnp probe */
{
struct ixj_softc *sc = device_get_softc(dev);
/* initialize softc
*/
bzero(sc, sizeof(struct ixj_softc));
/* get value from pnp probe */
if(ISA_PNP_PROBE(device_get_parent(dev), dev, ixj_ids) == ENXIO)
return ENXIO;
return (0);
}
static int
ixj_isa_attach (device_t dev)/* attach device */
{
/* int unit = device_get_unit(dev); */
struct ixj_softc *sc = device_get_softc(dev);
struct resource *res;
int rid;
int size;
printf("attaching device.\n");
if (sc-port_used 0) {
size = sc-port_used;
rid =
Need help with driver....
Hi all,
I'm a newbie to device driver writing and I have been learning well by
reading the code of the other drivers in the system. I would ultimately
like to port a linux driver for a VoIP telephony card (Quicknet
PhoneJack) to FreeBSD, and so far I have a skeleton driver which does
successfully probe the card.
The problem I'm having is that I don't know how to tell whether or not
the card is attaching correctly. How can I determine this? I thought
that I would be able to make a device file in /dev if it correctly
attached but MAKEDEV responds with:
{root@dbm /dev]# ./MAKEDEV phone
phone - no such device name
For reference, here is my attach routine:
static int
ixj_isa_attach (dev)/* attach device*/
device_t dev;
{
int unit = device_get_unit(dev);
struct ixj_softc *sc = device_get_softc(dev);
struct resource *res;
int rid;
int size;
if (sc-port_used 0) {
size = sc-port_used;
rid = sc-port_rid;
res = bus_alloc_resource(dev, SYS_RES_IOPORT, rid,
0, ~0, size, RF_ACTIVE);
if (res) {
sc-port_rid = rid;
sc-port_res = res;
sc-port_used = size;
}
}
make_dev(ixj_cdevsw, UNIT(dev), UID_ROOT, GID_WHEEL,
0666, "phone%d", unit);
return (0);
}
What am I doing wrong? How can I tell if this is working? Why can't I
make the device file?
Thanks in advance.
--
Regards, Devin.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
