|
|
|
|
|
|
| Author |
Message |
Alexander Leidinger
*nix forums addict
Joined: 16 Jun 2002
Posts: 59
|
 Posted: Wed Apr 19, 2006 7:53 am Post subject:
Re: Google's summer of code topics?
|
|
|
Quoting pfgshield-freebsd@yahoo.com (from Tue, 18 Apr 2006 21:48:32
+0200 (CEST)):
| Quote: | From my personal wishlist:
- A port of NetBSD's wscons.
- more KGI4BSD.
I don't know who could be a technical contact, well.. Nicholas for KGI, I
guess.
|
Not related to the SoC directly, but everyone is free to submit (plain
text) entries for the ideas list at
http://www.freebsd.org/projects/ideas/. They will be added if they
look sane and comply mostly to the style of the already existing
entries (we may try to improve submissions, and we may point out
deficiencies in them, so it doesn't needs to be perfect the first time).
Bye,
Alexander.
--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Observe yon plumed biped fine.
To activate its captivation,
Deposit on its termination,
A quantity of particles saline.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
 |
Sylvana Edgecomb
*nix forums beginner
Joined: 20 Apr 2006
Posts: 1
|
| Posted: Thu Apr 20, 2006 10:55 pm Post subject:
Re: nawov news
|
|
|
Dea r r Home Ow i ne q r ,
Your c p red x it doesn't matter to us ! If you O y WN real e g st f at
f e
and want I v MMED a IAT i E c y ash to sp k en f d ANY way you like, or
simply wish
to L g OWER your monthly p z aym z ents by a third or more, here are the
dea s ls
we have T t ODA u Y :
$ 4 i 88 , 000 at a 3 , g 67% f z ixed - rat z e
$ 3 r 72 , 000 at a 3 , s 90% v p ariabl z e - rat l e
$ 49 w 2 , 000 at a 3 , 2 m 1% i c ntere b st - only
$ 2 r 48 , 000 at a 3 , a 36% fi z xed - rat d e
$ 1 i 98 , 000 at a 3 , a 55% v j ariable - ra d te
Hurr i y, when these d x eaIs are gone, they are gone !
Don't worry about app x rov o al, your c g red b it will not d o
isqualif j y you !
Vi m si u t our si h te <http://EvdokffatonA.iwarp.com/>
Sincerely, Sylvana Edgecomb
Ap z pro f val Manager
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Colin Percival
*nix forums addict
Joined: 10 Dec 2004
Posts: 61
|
| Posted: Fri Apr 28, 2006 10:20 pm Post subject:
[HEADS UP] upcoming /etc/services updating
|
|
|
Michael Bushkov wrote:
| Quote: | - getservXXX() functions now work through nsdispatch(). "files", "nis"
and "compat" nsswitch sources are implemeted. "sources" and
"sources_compat" databases can now be specified in nsswitch.conf. The
idea of "services_compat" database is the same as for "passwd_compat"
and "group_compat": if we find "+" in /etc/services, we'll substitute it
with information received from the "services_compat" database's source.
|
Now that searching through a large /etc/services file is no longer a
performance bottleneck, I intend to merge most of IANA's port assignment
list into our /etc/services some time in mid-May.
If anyone objects to this, please let me know now.
Colin Percival
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Ceri Davies
*nix forums addict
Joined: 27 Apr 2003
Posts: 96
|
| Posted: Fri Apr 28, 2006 10:26 pm Post subject:
Re: [HEADS UP] upcoming /etc/services updating
|
|
|
On Fri, Apr 28, 2006 at 03:20:00PM -0700, Colin Percival wrote:
| Quote: | Michael Bushkov wrote:
- getservXXX() functions now work through nsdispatch(). "files", "nis"
and "compat" nsswitch sources are implemeted. "sources" and
"sources_compat" databases can now be specified in nsswitch.conf. The
idea of "services_compat" database is the same as for "passwd_compat"
and "group_compat": if we find "+" in /etc/services, we'll substitute it
with information received from the "services_compat" database's source.
Now that searching through a large /etc/services file is no longer a
performance bottleneck, I intend to merge most of IANA's port assignment
list into our /etc/services some time in mid-May.
If anyone objects to this, please let me know now.
|
Would it be wise to wait until cached is enabled by default?
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere |
|
| Back to top |
|
|
Colin Percival
*nix forums addict
Joined: 10 Dec 2004
Posts: 61
|
| Posted: Fri Apr 28, 2006 10:35 pm Post subject:
Re: [HEADS UP] upcoming /etc/services updating
|
|
|
Ceri Davies wrote:
| Quote: | On Fri, Apr 28, 2006 at 03:20:00PM -0700, Colin Percival wrote:
Now that searching through a large /etc/services file is no longer a
performance bottleneck, I intend to merge most of IANA's port assignment
list into our /etc/services some time in mid-May.
If anyone objects to this, please let me know now.
Would it be wise to wait until cached is enabled by default?
|
My (perhaps mistaken) impression was that cached was going to be
enabled by default soon in HEAD, and at very least long before
7.0-RELEASE. I wasn't planning on MFCing the /etc/services update
until cached was enabled by default in RELENG_6.
If there's a significant reason why people running HEAD would not
want to turn cached on, I'll certainly reconsider my plans here.
Colin Percival
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Giorgos Keramidas
*nix forums Guru
Joined: 10 May 2002
Posts: 330
|
| Posted: Fri Apr 28, 2006 10:49 pm Post subject:
Re: [HEADS UP] upcoming /etc/services updating
|
|
|
On 2006-04-28 15:35, Colin Percival <cperciva@freebsd.org> wrote:
| Quote: | Ceri Davies wrote:
Would it be wise to wait until cached is enabled by default?
My (perhaps mistaken) impression was that cached was going to
be enabled by default soon in HEAD, and at very least long
before 7.0-RELEASE. I wasn't planning on MFCing the
/etc/services update until cached was enabled by default in
RELENG_6.
If there's a significant reason why people running HEAD would
not want to turn cached on, I'll certainly reconsider my plans
here.
|
I think turning it on by default will give it more visibility and
testing on HEAD, so it's probably good to do so. Running CURRENT
and having new features shouldn't be a very big surprise for most
people I guess :)
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Hajimu UMEMOTO
*nix forums beginner
Joined: 16 Jun 2002
Posts: 46
|
| Posted: Sat Apr 29, 2006 4:03 am Post subject:
Re: [HEADS UP] upcoming /etc/services updating
|
|
|
Hi,
| Quote: | On Fri, 28 Apr 2006 15:35:25 -0700
Colin Percival <cperciva@freebsd.org> said:
|
cperciva> Ceri Davies wrote:
| Quote: | On Fri, Apr 28, 2006 at 03:20:00PM -0700, Colin Percival wrote:
Now that searching through a large /etc/services file is no longer a
performance bottleneck, I intend to merge most of IANA's port assignment
list into our /etc/services some time in mid-May.
If anyone objects to this, please let me know now.
Would it be wise to wait until cached is enabled by default?
|
cperciva> My (perhaps mistaken) impression was that cached was going to be
cperciva> enabled by default soon in HEAD, and at very least long before
cperciva> 7.0-RELEASE. I wasn't planning on MFCing the /etc/services update
cperciva> until cached was enabled by default in RELENG_6.
Though I committed it but not enabled by dafault, I think it is better
to enable it by default at least for testing. Okay, I'll enable it by
default.
cperciva> If there's a significant reason why people running HEAD would not
cperciva> want to turn cached on, I'll certainly reconsider my plans here.
We need to change /etc/nsswitch.conf. /etc/nsswitch.conf is not
installed, and generated by /etc/rc.d/nsswitch. So, mergemaster(
doesn't care of it. I worry about this issue, bit.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
?????? ??????
*nix forums beginner
Joined: 06 Mar 2004
Posts: 4
|
| Posted: Sat Apr 29, 2006 4:09 am Post subject:
Re: [HEADS UP] upcoming /etc/services updating
|
|
|
Hi!
Colin Percival wrote:
| Quote: |
Now that searching through a large /etc/services file is no longer a
performance bottleneck, I intend to merge most of IANA's port assignment
list into our /etc/services some time in mid-May.
If anyone objects to this, please let me know now.
Would it be wise to wait until cached is enabled by default?
|
Yes - and caching for services should be turned on in nsswitch.conf by
default too.
I think, that "perform-actual-lookups" mode should also be enabled for
"services" by default in cached.conf - so that the cache for services
information would be the same for all users. Besides, as services
information changes extremely rarely, I'd also suggest putting greater TTL
values for "services" in the cached.conf.
With best regards,
Michael Bushkov
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Matteo Riondato
*nix forums beginner
Joined: 29 Apr 2006
Posts: 1
|
| Posted: Sat Apr 29, 2006 9:31 am Post subject:
Re: [HEADS UP] upcoming /etc/services updating
|
|
|
On Sat, Apr 29, 2006 at 01:03:38PM +0900, Hajimu UMEMOTO wrote:
| Quote: | Colin Percival <cperciva@freebsd.org> said:
cperciva> If there's a significant reason why people running HEAD would not
cperciva> want to turn cached on, I'll certainly reconsider my plans here.
We need to change /etc/nsswitch.conf. /etc/nsswitch.conf is not
installed, and generated by /etc/rc.d/nsswitch. So, mergemaster(
doesn't care of it. I worry about this issue, bit.
|
An entry in UPDATING will probably be enough, IMHO. Something like:
"cached $SHORT_DESCRIPTION_OF_CACHED is now turned on by default.
To use it you need to update your /etc/nsswitch.conf . This can be
done with the following commands:
# rm /etc/nsswitch.conf
# /etc/rc.d/nsswitch restart
"
Or something similar..
Thanks for your work.
Best Regards
--
Matteo Riondato
FreeBSD Committer (http://www.freebsd.org)
G.U.F.I. Staff Member (http://www.gufi.org)
FreeSBIE Developer (http://www.freesbie.org)
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Ceri Davies
*nix forums addict
Joined: 27 Apr 2003
Posts: 96
|
| Posted: Sat Apr 29, 2006 10:02 am Post subject:
Re: [HEADS UP] upcoming /etc/services updating
|
|
|
On Sat, Apr 29, 2006 at 08:09:35AM +0400, Michael Bushkov wrote:
| Quote: | Hi!
Colin Percival wrote:
Now that searching through a large /etc/services file is no longer a
performance bottleneck, I intend to merge most of IANA's port assignment
list into our /etc/services some time in mid-May.
If anyone objects to this, please let me know now.
Would it be wise to wait until cached is enabled by default?
Yes - and caching for services should be turned on in nsswitch.conf by
default too.
|
Good point.
| Quote: | I think, that "perform-actual-lookups" mode should also be enabled for
"services" by default in cached.conf - so that the cache for services
information would be the same for all users.
|
So "perform-actual-lookups" essentially creates a system-wide cache?
| Quote: | Besides, as services
information changes extremely rarely, I'd also suggest putting greater TTL
values for "services" in the cached.conf.
|
Yes, the services cache could always be flushed by the superuser after
changing the services data source.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere |
|
| Back to top |
|
|
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Sat Apr 29, 2006 4:44 pm Post subject:
Re: [HEADS UP] upcoming /etc/services updating
|
|
|
On Sat, 29 Apr 2006, Ceri Davies wrote:
| Quote: | I think, that "perform-actual-lookups" mode should also be enabled for
"services" by default in cached.conf - so that the cache for services
information would be the same for all users.
So "perform-actual-lookups" essentially creates a system-wide cache?
Besides, as services information changes extremely rarely, I'd also
suggest putting greater TTL values for "services" in the cached.conf.
Yes, the services cache could always be flushed by the superuser after
changing the services data source.
|
Very few sites use distributed services databases (at least, that I've ever
seen). Performing stat() on /etc/services to check the last modification date
is pretty light-weight, and probably worth doing. What you don't want is
someone modifying /etc/services, restarting the daemon immediately, and having
it fail due to an added service not being found. Likewise for other local
databases.
BTW, since this is in the context of significantly increasing the size of the
services database, have we:
(1) Measured what impact adding the cache daemon for local databases has?
Specifically, does adding the cache daemon for a database like
/etc/services, /etc/passwd, etc, improve performance, or add overhead?
(2) Looked at adding /etc/services.db, similar to the other compiled database
pieces, in order to improve lookup times for very large tables. This
change would be orthoganal to a cache daemon.
Robert N M Watson
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
?????? ??????
*nix forums beginner
Joined: 06 Mar 2004
Posts: 4
|
| Posted: Thu May 04, 2006 5:28 pm Post subject:
Re: [HEADS UP] upcoming /etc/services updating
|
|
|
Hi,
| Quote: | Robert Watson wrote:
BTW, since this is in the context of significantly increasing the size of
the services database, have we:
(1) Measured what impact adding the cache daemon for local databases has?
Specifically, does adding the cache daemon for a database like
/etc/services, /etc/passwd, etc, improve performance, or add overhead?
(2) Looked at adding /etc/services.db, similar to the other compiled
database
pieces, in order to improve lookup times for very large tables. This
change would be orthoganal to a cache daemon.
|
getpwXXX() and getgrXXX() functions work slower in about 3 times with cached
enabled when only "files" source is used. The thing is, I think, I'll be
able to improve cached's performance to reduce this drawback. Currently,
cached gives real performance gain with sources such as DNS and LDAP and is
not that useful with local sources, except the "services" database (I'll do
accurate benchmarking with all types of sources and will post the report
with its results). I'll test the cached performance with very large
/etc/services file. However, at this moment, the solution with compiled
database for services will be probably faster. Anyway, cached can be used
right now to allow IANA list importing without significant performance
drawbacks, IMHO.
With best regards,
Michael Bushkov
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
gnn@freebsd.org
*nix forums beginner
Joined: 11 Aug 2005
Posts: 15
|
| Posted: Mon May 22, 2006 11:50 pm Post subject:
Re: doxygen target (was: Re: cvs commit: src Makefile.inc1 ObsoleteFiles.inc src/etc/defaults rc.conf src/etc/mtree BSD.usr.dist src/etc/rc.d Makefile isdnd pcvt syscons src/release/picobsd/build picobsd src/share/man/man4 Makefile atkbd.4 kbdmux.4 pcvt.4
|
|
|
At Mon, 22 May 2006 10:18:25 +0200,
Alexander Leidinger wrote:
| Quote: |
Quoting gnn@neville-neil.com (from Sun, 21 May 2006 14:48:37 -0700):
At Fri, 19 May 2006 14:31:16 +0200,
Alexander Leidinger wrote:
Quoting "George V. Neville-Neil" <gnn@neville-neil.com> (from Thu, 18
May 2006 10:14:26 -0700):
I so hate to chime in on this thread, but I really think we need to
start putting things into the code and using Doxygen, or a moral
equivalent, to at least have a chance of keeping such things up to
date. Someone a while back set up a proper Doxygen file for use with
FreeBSD and we might simply pursue that tack.
http://www.leidinger.net/FreeBSD/src_docs/
http://www.leidinger.net/FreeBSD/FreeBSD-Dox.tar.bz2
Feel free to send/suggest further subsystems/improvements.
The one thing I'd like to suggest is that this be made part of the
tree with an optional make target. How should we go about doing that?
We already have a doxygen config file in the tree, it covers the
entire kernel. But I think my approach of generating docs for
subsystems instead of the entire kernel may be more easy to understand
for people which want to understand a part of the kernel.
|
BTW I have move this to arch@ since I think it makes more sense there.
| Quote: | Regarding the make target, do you think about "cd /usr/src; make
doxygen" or about "cd /usr/src/<mumble>; make doxygen"?
|
Yes  It hsould be possible to be as specific or non-specific as
possible. There can then be nightly builds of the docs, much like
running global nightly to get cross references like I put up on
codespelunking.org
| Quote: | The targets in the .tar.bz2 generate a HTML version too. Currently
the HTML version is around 300 MB, and it only covers a small part
of the kernel. Shall the HTML version also be generated (not
available online)? What about the destination, where do you want the
HTML version and/or the PDF version (needs pdflatex as a build tool)
to be placed (I can't come up with a good destination)? The HTML
version is generated by doxygen directly, the PDF needs to be
generated from the latex version, so in case of the PDF version it
would make sense to have a "doxygen" and "doxygeninstall" target,
but not for the HTML version (except you want to generate everything
in OBJDIR and then do a copy to the destination).
Yes, I'm asking bikeshed questions... but only because I can't think
of a good answer myself ATM.
|
My preference, and I'm not a Doxygen guru, is that we generate HTML
from /usr/src into a /usr/doc directory, which is like /usr/obj, then
some folks can serve /usr/doc on the net. Sub directory builds should
make sub-directory doc directories. I.e. /usr/src/sys/netinet/doc. I
think that /usr/src/sys is already a special root which gets a doc
directory, and I think that's fine. For now I want to emphasize
simplicity.
THe other thing we need guidance on is, if people want to, how to most
easily add clear annotations to soiurce that make Doxygen happy. A
one page cheat sheet would go a long way towards making this usable by
people who don't like to write documentation :-)
Thanks,
George
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Wallace William
*nix forums beginner
Joined: 06 May 2006
Posts: 2
|
| Posted: Tue May 23, 2006 1:16 am Post subject:
Re: misc questions about the device&driver arch
|
|
|
I just have fossicked some idea from scottl@samsco.org "PCI-Express support "
PCI-Express support
All,
I've emailed before about supporting various aspects of PCI-Express and
especially MSI, but haven't really gotten too far with it due to lack of
resources. I now how access to a system that can do PCI-Express (PCI-E)
so I'd like to revisit it and see what can be added for 5-STABLE. There
are three general areas that need to be addressed in some form or another:
Enhanced Configuration Space:
PCI-E introduces an enhanced PCI Configuration space that allows for
each function to have 4096 bytes of space instead of just 256. The
Intel Lindenhurst chipset exposes this space via a memory-mapped
window instead of the old slow type 1/2 ioport configuration methods.
It appears that if the northbridge supports the enhanced config space
then all PCI, PCI-X, and PCI-E devices will show up in it as well as
in the legacy space.
Proper support likely entails splitting up the pci host-bridge drivers
so that a given ACPI or legacy front-end can plug into a given enhanced
or legacy configuration layer. This definitely is not going to happen
in time for 5.3, though. A hack that could work for 5-STABLE would be
to provide pcie_[read|write]_config() methods that would compliment the
existing pci methods and be available for drivers that want to access
the >255 configuration addresses. Devices are already showing up that
want to use these registers, btw. The mechanics of doing this would
involve using pmap_mapdev() to map in the range that is specific to each
function, and then hang this information off of the pcicfg structure.
It's a bit hackish, yes, but it does seem to work in tests that a
colleague of mine has done.
MSI:
I've bantered around different suggestions for an API that will support
this. The basic thing that a driver needs from this is to know
exactly how many message interrupt vectors are available to it. It
can't just register vectors and handlers blindly since the purpose of
MSI is to assign special meanings to each vector and allow the driver to
handle each one in specifically.
In order to keep the API as consistent as possible between classic
interrupt sources and MSI sources, I'd like to add a new bus method:
int
bus_reserve_resource(device_t, int *start, int *end, int *count, int flags);
start, end, and count would be passed is as the desired range and would
map to the per-function interrupt index in MSI. On return, the range
supported and negotiated by the OS, bus, and function would be filled
into these values. flags would be something like SYS_RES_MESSAGE.
Internal failure of the function would be given in the return value.
Whether failure to support MSI should be given as an error code return
value can be debated. This function will also program the MSI
configuration registers on the device to use the correct message cookie
and number of messages.
Interrupt registration would then proceed as normal with paired calls to
bus_alloc_resource() and bus_setup_intr() for each desired interrupt
index. The individual function interrupt index would be used as the
start and end parameters to bus_alloc_resource(), and the type parameter
would be SYS_RES_MESSAGE instead of SYS_RES_IRQ. bus_setup_intr() would
unmask the source in the MSI APIC just like normal.
Adding this for 5.3 is feasible, I think, and doesn't add a whole lot
of risk. PCI-E provides a legacy mde for interrupts that simulates
PCI interrupt lines, so drivers can choose whether to use MSI or the
legacy interrupt methods.
Hot-Plug, lane status, lane bonding:
We don't have the infrastructure to support PCI or PCI-E hot-plug. It's
also debatable whether this information will actually be available in a
standard form. The PCI-E spec defines a new extended capabilities
structure in the config space that can provide some of this information,
but these kinds of things have a history of the vendors choosing their
own proprietary methods and ignoring the standard. In short, we can't
deal with this in the short term at all, and likely not in the long term
without significant work to the bus and device infrastructure.
On 5/22/06, Warner Losh <imp@bsdimp.com> wrote:
| Quote: | That happens at attach time. Cardbus right now has a private protocol
between the card bus bridge (cbb) and the bus to know when there's a
new card in a slot and to enumerate that bus.
i think that 's because in cardbus protocol ,one bus only have one
device ,so does pci express port (port :device =1:1)
Cool. I just bought a new laptop yesterday. It has an expresscard
slot, which I think is handled as a PCI Express port (or USB 2.0 port,
depending on the card that's inserted).
so there will be a long list of methods in the future hotplug pci
driver and pcib driver
SHPC interface ..
.......
PCIE interface
.......
compaq interface
.......
IBM interface ....
.......
poer interface
.......
Yes. If ExpressCard isn't handled by the PCIe interface, then we'd
want to add it to the list as well.
Warner
|
--
we who r about to die,salute u!
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
John-Mark Gurney
*nix forums addict
Joined: 16 Jun 2003
Posts: 89
|
| Posted: Tue May 23, 2006 2:07 am Post subject:
Re: misc questions about the device&driver arch
|
|
|
william wallace wrote this message on Tue, May 23, 2006 at 09:16 +0800:
| Quote: | In order to keep the API as consistent as possible between classic
interrupt sources and MSI sources, I'd like to add a new bus method:
int
bus_reserve_resource(device_t, int *start, int *end, int *count, int flags);
start, end, and count would be passed is as the desired range and would
map to the per-function interrupt index in MSI. On return, the range
supported and negotiated by the OS, bus, and function would be filled
into these values. flags would be something like SYS_RES_MESSAGE.
Internal failure of the function would be given in the return value.
Whether failure to support MSI should be given as an error code return
value can be debated. This function will also program the MSI
configuration registers on the device to use the correct message cookie
and number of messages.
|
Why not create a wrapper, and start at the highest requested, and slowly
work your way down as the requests are rejected.. since the number of
messages must be a power of two, it isn't than many rounds..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 6:21 am | All times are GMT
|
|
Credit Cards | Debt Management | Hipster Blog | Shares | Current Accounts
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
