Great FICL Hacks
I've been playing around with the boot loader(8), which seems to be a very powerful piece of software. However I'm really only using the 'load', 'unload', and 'boot' functions. I'd be interested in hearing about more powerful uses of this software. Are there any great hacks of FICL that people have done? Regards, Mike Kennett To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Use of newbus in sys/pci/pci.c
Hello All,
I have a question on the sys/pci/pci.c code, and its use of the
newbus architecture. An example of the code in question is:
static struct resource *
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
u_long start, u_long end, u_long count, u_int flags)
{
struct pci_devinfo *dinfo = device_get_ivars(child);
^ Looks wrong
struct resource_list *rl = dinfo-resources;
return resource_list_alloc(rl, dev, child, type, rid,
start, end, count, flags);
}
I don't understand the line that extracts the ivars from the child
device. Isn't it the case that the ivars are a property of the bus
device (dev)? In any case, the child device might not be directly
descended from the pci bus (e.g. it could be attached thru' the
bridge isab0: VIA 82C586 PCI-ISA bridge).
It strikes me that the assignment is unsafe. I would have thought
that the code should be:
static struct resource *
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
u_long start, u_long end, u_long count, u_int flags)
{
struct pci_devinfo *dinfo = device_get_ivars(dev);
^^^ CHANGED
struct resource_list *rl = dinfo-resources;
return resource_list_alloc(rl, dev, child, type, rid,
start, end, count, flags);
}
Why are the ivars extracted from the child, and not the bus device?
Kind Regards,
Mike Kennett
([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard disruptions : how did it go?
Hi Warner, Thanks for your detailed writeup of the direction that you want to go in. What can you do to help? Well, firstly I'd like to get the xe driver under FreeBSD. But before I even get to that stage, I'll have to learn about the pccard subsystem, and more about the FreeBSD kernel internals. I've had a look at the man pages Doug Rabson wrote for the device attach code - they are very good - and thought about writing a man page for pccard (4) that would detail the ioctl's provided by the system, and other man pages that would detail the design of the pccard subsystem. I suppose the eventual goal of this work would be to have a 'howto-write-a-pccard-driver-for-freebsd' howto. In any case, before porting the xe driver I'll have to have a clue on how to do the port, so this howto should be an easy by-product. I've got -current (12th dec sources) on an IBM 365X, and I can/will use that box for testing. Unfortunately, the network connection is by floppy-net, and so I'm not too keen on reinstalling lots of software on it. But I'll try to track -current reasonably closely (fortnightly). As usual, I'm constrained on time. So I'm not going to make any commitments on getting stuff done! By the same token, I don't expect anyone else to get anything done, and I'll certainly not make demands on FreeBSD, or its developers. I doubt that I'd get the xe driver ported before 4.0 is released. What help do you require? Regards, Mike Kennett ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pccard disruptions : how did it go?
Hello All, I've just scoured the archives, and found a thread from late October 1999 titled: Massive pccard disruptions to continue So, have these disruptions continued? And what is the current status with pccard support in the kernel? I've noticed that a few files still contain the PCCARD_MODULE macro - in particular, the dev/pccard/if_xe.c Xircom driver. I'm interested in getting the if_xe.c driver to work under -current (12-Dec sources). I'd be interested in any ideas on how to convert the old if_xe.c driver to the 'newbus' code. (I'm not familiar with either the old PCCARD_MODULE, or the newbus code.) Regards, Mike Kennett ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard disruptions : how did it go?
Warner wrote: In message [EMAIL PROTECTED] Michael Kennett writes: : I've just scoured the archives, and found a thread from late October 1999 : titled: : Massive pccard disruptions to continue : : So, have these disruptions continued? And what is the current status with : pccard support in the kernel? The new pccard code is still being worked on. To confirm: The new pccard code contains the `controller pccard' config directive. - the source code is in sys/dev/pcic sys/dev/pccard The old pccard code contains the `controller card' config directive. - the source code is in sys/pccard Is this correct ? However, the old pccard code mostly works again, modulo a couple of if_detach issues that I'm trying to work through. : I've noticed that a few files still contain the PCCARD_MODULE macro : - in particular, the dev/pccard/if_xe.c Xircom driver. I'm : interested in getting the if_xe.c driver to work under -current : (12-Dec sources). I'd be interested in any ideas on how to convert : the old if_xe.c driver to the 'newbus' code. (I'm not familiar with : either the old PCCARD_MODULE, or the newbus code.) The if_xe and if_fe drivers no longer work for pccard. You may wish to investigate how the ep and ed drivers were converted. There is one issue with the if_xe driver, namely it needs to access the CIS of the card to determine which kind of card it is and that will need some work in -current to get working again... I can provide support for this effort, but I'm not sure that I have time to do this effort. Thank you for your help. I'm not asking you to do it all, but instead what needs to be done, and in what direction I should be going! I think hacking the xe driver to work with the newbus kludge is less than desirable. Instead, I'd like to aim for support under the new pccard code. However, I've noticed that the file /dev/pcic/i82365_isasubr.c is missing from the Dec 12 -current sources, and compilation fails for `controller pccard'. Regards, Mike Kennett ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Developer assessment (was Re: A bike shed ...)
On a slight tangent, I've just gone back and reread Greg Lehey's 'How to get best results from FreeBSD-questions'. It's a great document, covering a lot of the etiquette for the freebsd-questions mailing list. It can be found at: http://www.lemis.com/questions.html However, the document doesn't really cover how 'newbies' (I hate that term :-) can find information for themselves. There is a huge amount of information on the internet -- too much, really -- and having a list of selected references could help people help themselves. This 'how-to-help-yourself' document wouldn't have to be long. But it could contain references to the FreeBSD handbook, the FAQ, and other stuff that people put together (eg. Gregs pages on vinum, Brian Somers pages on ppp, + many others), in addition to some general internet resources (eg. www.faqs.org), and general unix introductions. Ideally, this 'meta-FAQ' would only be a few pages in length. It's role would be as a quick signpost to material that people have found useful before. I just did a quick check on www.faqs.org, and there were *no* faqs posted for FreeBSD on that site (at least that I could find). I think it would certainly be worthwhile to have a FAQ listed on that site. I'd appreciate feedback on this. I'm willing to collate material and host such a FAQ (with the advance warning that I have *lousy* HTML skills:-). Please suggest any information or worthy sites that you think of. Looking forward to your comments, Mike 'forever-a-newbie-willing-to-learn' Kennett ([EMAIL PROTECTED]) Jeroen wrote: [ snip good advice ] Now this is very good advice. I am certainly going to keep Darryl's comments somewhere for easy reference in order to make sure I at least never forget where I came from and how to treat others. I think everybody should heed this advice. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: keeping termcap up to date
I just wonder why don't we just import termcap database from the master site: http://www.tuxedo.org/terminfo, rather than maintaining our own copy? Minor correction: the URL is http://www.tuxedo.org/~esr/terminfo. Mike Kennett To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GNU GLOBAL
Hi Shigio, As the owner/author of a piece of software, you can distribute the source code under any license that you like (GNU/BSD/Artistic etc...). Indeed, there is no reason to choose just a single license under which you distribute your code -- it should be possible for you to distribute the code under *both* the GPL and the BSD licenses. E.g. you could distribute a BSD version of GLOBAL-3.53 at the same time that you distribute a GNU License version of GLOBAL-3.53. If you want to assign copyright to the Free Software Foundation (so that global becomes gnu-global?), I think you will lose the right to distribute later versions under the BSD license. Whether this is what you want or not is only for you to decide! Best of Luck, Mike Kennett. Usual Disclaimer: I'm not a legal expert, and the above represents my opinion only. Potential Flamebait (:-)) [[Feel free to ignore this comment]] Does the license really matter? Surely the important consideration is quality of the code? I'm the author of GLOBAL source code tag system. I have decided to release next version of GLOBAL as a GNU software. It means that it will be released under GPL instead of BSD license. This decision was made by practical reason, not by doctrine reason. It is advantageous for GLOBAL, because o GNU softwares are distributed to widespread environments. o The developers of GNU software pay some attention to making the program work well with the rest of GNU software. That makes it easy for GLOBAL to reach the goal, that is, becoming a common source code tag system in various environments. Since FreeBSD already includes GNU softwares, it seems no problem. GLOBAL itself will be as it be. I'm concerned about whether or not FreeBSD community accept GNU GLOBAL. I hope you not to reject it, because the rejection splits GLOBAL and it makes it hard for GLOBAL to be a common source code tag system. By the way, I have released GLOBAL-3.53 today. http://www.tamacom.com/unix/ It supports C++, XEmacs and WIN32 and includes improved gtags.el. (Of course, it's BSD licensed). Thank you. -- Shigio Yamaguchi - Tama Communications Corporation Mail: [EMAIL PROTECTED], WWW: http://www.tamacom.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GNU GLOBAL
Hi Shigio, As the owner/author of a piece of software, you can distribute the source code under any license that you like (GNU/BSD/Artistic etc...). Indeed, there is no reason to choose just a single license under which you distribute your code -- it should be possible for you to distribute the code under *both* the GPL and the BSD licenses. E.g. you could distribute a BSD version of GLOBAL-3.53 at the same time that you distribute a GNU License version of GLOBAL-3.53. If you want to assign copyright to the Free Software Foundation (so that global becomes gnu-global?), I think you will lose the right to distribute later versions under the BSD license. Whether this is what you want or not is only for you to decide! Best of Luck, Mike Kennett. Usual Disclaimer: I'm not a legal expert, and the above represents my opinion only. Potential Flamebait (:-)) [[Feel free to ignore this comment]] Does the license really matter? Surely the important consideration is quality of the code? I'm the author of GLOBAL source code tag system. I have decided to release next version of GLOBAL as a GNU software. It means that it will be released under GPL instead of BSD license. This decision was made by practical reason, not by doctrine reason. It is advantageous for GLOBAL, because o GNU softwares are distributed to widespread environments. o The developers of GNU software pay some attention to making the program work well with the rest of GNU software. That makes it easy for GLOBAL to reach the goal, that is, becoming a common source code tag system in various environments. Since FreeBSD already includes GNU softwares, it seems no problem. GLOBAL itself will be as it be. I'm concerned about whether or not FreeBSD community accept GNU GLOBAL. I hope you not to reject it, because the rejection splits GLOBAL and it makes it hard for GLOBAL to be a common source code tag system. By the way, I have released GLOBAL-3.53 today. http://www.tamacom.com/unix/ It supports C++, XEmacs and WIN32 and includes improved gtags.el. (Of course, it's BSD licensed). Thank you. -- Shigio Yamaguchi - Tama Communications Corporation Mail: shi...@tamacom.com, WWW: http://www.tamacom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Crossing building alpha world fails
Hello All, I've been trying to cross-build the alpha port of freebsd (from x86). The build is failing in src/gnu/usr.bin/binutils. The command I've issued is: TARGET=alpha TARGET_ARCH=alpha MACHINE=alpha MACHINE_ARCH=alpha \ make buildworld Is this the correct command to use for building the cross? The source code tree is from freebsd-current, taken as of today. The build failed with yesterdays -current as well. Any help is appreciated. Michael Kennett (m...@laurasia.com.au) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
