Nabble - freebsd-new-bus

link exchange

2009-11-30T03:08:03Z

Hello,

I'm webmaster of this websites :- http://www.bluedelightconsultant.com/

i'm making some links for this projects to get more visitors and to get high
populirity to this site.So would you like to link exchange with this site.?
I'm looking for reciprocal links but in deep case i will be agree to add 3
way sites. This will be benifit for both of us.

My detail is:-

Title:- SEO Company
Url:- http://www.bluedelightconsultant.com/
Desc:- Professional Search Engine Optimization(Seo) Services Placement
Company India.

After add my let me know via mail here- karan.nathawat@...

I'll give you backlink at following pages.....

Link Back:-http://www.bluedelightconsultant.com/seo_sites.html

I'm waiting a positive reply from your side..

Best regards !

Karan Singh

karan.nathawat@...
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Collapsing device_state_t with devinfo_state_t

2009-11-08T18:02:21Z

2009/11/9 Scott Long <scottl@...>:

> On Nov 8, 2009, at 9:53 AM, Attilio Rao wrote:
>>
>> This patch should collpase device_state_t with devinfo_state_t and
>> remove a bogus replication of this struct:
>> http://www.freebsd.org/~attilio/devinfo.diff
>>
>> This patch breaks ABI so it cannot be MFC'ed (and it is not intended to
>> do).
>>
>
> Does this hinder FreeBSD 8 from ever getting a Giant-free newbus?

As foretold in several e-mails and threads, FreeBSD-8 has all the
needed support for Giant-free newbus, that's just an improvement I
couldn't let happen before because we had to maintain ABI stability
over the release process, but it doesn't compromise at all possibility
to MFC Giant-free newbus.

Attilio

--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Collapsing device_state_t with devinfo_state_t

2009-11-08T17:40:48Z

On Nov 8, 2009, at 9:53 AM, Attilio Rao wrote:
> This patch should collpase device_state_t with devinfo_state_t and
> remove a bogus replication of this struct:
> http://www.freebsd.org/~attilio/devinfo.diff
>
> This patch breaks ABI so it cannot be MFC'ed (and it is not intended
> to do).
>

Does this hinder FreeBSD 8 from ever getting a Giant-free newbus?

Scott

_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Collapsing device_state_t with devinfo_state_t

2009-11-08T17:25:56Z

In message: <3bbf2fe10911080854x64d18e40hf639634e625dd11b@...>
Attilio Rao <attilio@...> writes:
: 2009/11/8 Attilio Rao <attilio@...>:
: > This patch should collpase device_state_t with devinfo_state_t and
: > remove a bogus replication of this struct:
: > http://www.freebsd.org/~attilio/devinfo.diff
:
: Sorry, forgot to mention:
: I thought about adding _bus.h interface because I thought that
: devinfo.h wanted to avoid a namespace pollution, but that's not really
: the case as 85% of the bus.h is already under _KERNEL labels. That
: means the pollution is minimal and restricted to 1-2 further structs.

I'm cool with this patch, and that decision.

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Collapsing device_state_t with devinfo_state_t

2009-11-08T08:54:50Z

2009/11/8 Attilio Rao <attilio@...>:
> This patch should collpase device_state_t with devinfo_state_t and
> remove a bogus replication of this struct:
> http://www.freebsd.org/~attilio/devinfo.diff

Sorry, forgot to mention:
I thought about adding _bus.h interface because I thought that
devinfo.h wanted to avoid a namespace pollution, but that's not really
the case as 85% of the bus.h is already under _KERNEL labels. That
means the pollution is minimal and restricted to 1-2 further structs.

Attilio

--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Collapsing device_state_t with devinfo_state_t

2009-11-08T08:53:20Z

This patch should collpase device_state_t with devinfo_state_t and
remove a bogus replication of this struct:
http://www.freebsd.org/~attilio/devinfo.diff

This patch breaks ABI so it cannot be MFC'ed (and it is not intended to do).

Thanks,
Attilio

--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Buffer overflow in devclass_add_device()

2009-11-06T08:45:18Z

On Friday 06 November 2009 11:15:43 am M. Warner Losh wrote:

> In message: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@...>
> Attilio Rao <attilio@...> writes:
> : A buffer overflow is possible in devclass_add_device().
> : More specifically, the dev nameunit construction is based on the
> : assumption that the unit linked with the device is invariant but that
> : can change when calling devclass_alloc_unit() (because -1 is passed
> : or, more simply, because the unit choosen is beyond the table limits).
> : This results in a buffer overflow if the bug is too short on the
> : second snprintf().
> : This patch should fix it:
> : http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff
> :
> : aiming for the max possible number of digits necessary.
> : This bug has been found by Sandvine Incorporated.
> : Please reivew.
>
> I don't see a problem with it, except you'd want -INT_MAX to be
> paranoid, since it is one character longer (or just add 1) :)
>
> However, it might be better to just allocate strlen(dc->name) +
> log10(INT_MAX) + 2 and not have snprintf do that calculation. But it
> doesn't look like there's a compile-time constant for that...

In this case I think the snprintf() is fine as code-wise I think it is simpler
(it matches up well with the later snprintf() to fill out the buffer). Given
that adding devices isn't generally a critical-path, I think the clarity is
worth the probably quite small additional cost of snprintf().

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Buffer overflow in devclass_add_device()

2009-11-06T08:38:47Z

In message: <3bbf2fe10911060822g35b81099ib6fa53473d7c20fe@...>
Attilio Rao <attilio@...> writes:
: 2009/11/6 M. Warner Losh <imp@...>:
: > In message: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@...>
: > Attilio Rao <attilio@...> writes:
: > : A buffer overflow is possible in devclass_add_device().
: > : More specifically, the dev nameunit construction is based on the
: > : assumption that the unit linked with the device is invariant but that
: > : can change when calling devclass_alloc_unit() (because -1 is passed
: > : or, more simply, because the unit choosen is beyond the table limits).
: > : This results in a buffer overflow if the bug is too short on the
: > : second snprintf().
: > : This patch should fix it:
: > : http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff
: > :
: > : aiming for the max possible number of digits necessary.
: > : This bug has been found by Sandvine Incorporated.
: > : Please reivew.
: >
: > I don't see a problem with it, except you'd want -INT_MAX to be
: > paranoid, since it is one character longer (or just add 1) :)
:
: I don't think that unit number can grow negative, can they?

They can't, but this is about an abundance of caution, right?

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Buffer overflow in devclass_add_device()

2009-11-06T08:22:36Z

2009/11/6 M. Warner Losh <imp@...>:

I don't think that unit number can grow negative, can they?

Thanks,
Attilio

--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Buffer overflow in devclass_add_device()

2009-11-06T08:15:43Z

In message: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@...>
Attilio Rao <attilio@...> writes:
: A buffer overflow is possible in devclass_add_device().
: More specifically, the dev nameunit construction is based on the
: assumption that the unit linked with the device is invariant but that
: can change when calling devclass_alloc_unit() (because -1 is passed
: or, more simply, because the unit choosen is beyond the table limits).
: This results in a buffer overflow if the bug is too short on the
: second snprintf().
: This patch should fix it:
: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff
:
: aiming for the max possible number of digits necessary.
: This bug has been found by Sandvine Incorporated.
: Please reivew.

I don't see a problem with it, except you'd want -INT_MAX to be
paranoid, since it is one character longer (or just add 1) :)

However, it might be better to just allocate strlen(dc->name) +
log10(INT_MAX) + 2 and not have snprintf do that calculation. But it
doesn't look like there's a compile-time constant for that...

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Buffer overflow in devclass_add_device()

2009-11-06T07:43:52Z

On Friday 06 November 2009 10:20:35 am Attilio Rao wrote:

> A buffer overflow is possible in devclass_add_device().
> More specifically, the dev nameunit construction is based on the
> assumption that the unit linked with the device is invariant but that
> can change when calling devclass_alloc_unit() (because -1 is passed
> or, more simply, because the unit choosen is beyond the table limits).
> This results in a buffer overflow if the bug is too short on the
> second snprintf().
> This patch should fix it:
> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff
>
> aiming for the max possible number of digits necessary.
> This bug has been found by Sandvine Incorporated.
> Please reivew.

Looks ok to me.

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Buffer overflow in devclass_add_device()

2009-11-06T07:20:35Z

A buffer overflow is possible in devclass_add_device().
More specifically, the dev nameunit construction is based on the
assumption that the unit linked with the device is invariant but that
can change when calling devclass_alloc_unit() (because -1 is passed
or, more simply, because the unit choosen is beyond the table limits).
This results in a buffer overflow if the bug is too short on the
second snprintf().
This patch should fix it:
http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff

aiming for the max possible number of digits necessary.
This bug has been found by Sandvine Incorporated.
Please reivew.

Thanks,
Attilio

--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Bank Of America Online Alert : Verify Your Information ID# d885f20cbd1f2d7442e324bc1bcdb689

2009-07-07T01:19:25Z

[mhd_reg_logo.gif]
[em_title_red.gif]

Dear customer,

Protecting the security of our customers and the Bank of America !
network , as a preventative measure, we have temporarily limited
access to sensitive account features.

To restore your account access, please take the following steps to
ensure that your account has not been compromised:

After updates :

1.Login to your Bank of America Online Banking account. In case you
are not enrolled for Online Banking, you will have to fill in all the
required information, including your name and you account number.

2. Review your recent account history for any unauthorized withdrawals
or deposits, and check you account profile to make sure not changes
have been made. If any unauthorized activity has taken place on your
account, report this to Bank of America staff immediately.

To get started, please click the link below:
!

[1]https://sitekey.bankofamerica.com/sas/signon.do?&detect=3&p=d41d8cd
98f00b204e9800998ecf8427e3265464
_________________________________________________________________

This alert has been sent to you based on your preferences. If you
would like to make any changes to your Online Banking Alerts service,
please sign in to Online Banking and visit the Manage Alerts section.

Because your reply will not be transmitted via secure e-mail, the
e-mail address that generated this alert will not accept replies. If
you would like to contact Bank of America with questions or comments,
please sign in to Online Banking and visit the customer service
section.
_________________________________________________________________

Bank of America, N.A. Member FDIC. Equal Housing Lender
© 2009 Bank of America Corporation. All rights reserved
d885f20cbd1f2d7442e324bc1bcdb689
_________________________________________________________________

References

1. http://indietones.net/preview/Onlineid.bankofameri!ca.com/cgi-bini/668d93445065081fa9f2b085cbde792e0d2e0da50a9b4260a03c403a83c60055efdf4a1c/c7206040b068b58cba7fadd6a5b4e341/bofa/ibdIAS/bankofamerica/signon.php?section=signinpage&update=&cookiecheck=yes&destination=nba/signin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Adding support for multiple boot-time passes of the device tree

2009-05-19T12:10:22Z

If you were at BSDCan a few weeks ago you may have seen my proposal for
extending new-bus to support multiple scans of the device tree during
boot-time probing. This patch is the infrastructure work to allow multiple
passes. It does not move any drivers (except root0 which is already special)
into an early pass, so all devices will still probe as a single pass for now.
However, getting this in now before 8.0 will enable folks to start working on
other problems such as resource discovery and management and will get the ABI
set before the 8.0 feature freeze. The paper where I go into greater detail
about the rationale and implementation is available at
http://www.FreeBSD.org/~jhb/papers/bsdcan/2009/. The actual patch is
available for review at http://www.FreeBSD.org/~jhb/patches/multipass.patch

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Web Design Logo Design Related Link Exchange Request

2009-02-24T06:43:51Z

Dear owner of http://lists.freebsd.org,

I'm the webmaster of http://www.onlinemarketingseo.com/.

We came across your site on the Internet and feel that it would fit
perfectly into our collection of quality web design-related links at
http://www.onlinemarketingseo.com/.

The Google PR of this site is currently 3.

We've already placed a link to your web site along with a description
at our site on the http://www.onlinemarketingseo.com/partners-logo-designer10.html page,
which we encourage you to check for accuracy.

We'd appreciate it if you place a link back to our site using the
following HTML code (just copy and paste it into your links page):

<a href="http://www.onlinemarketingseo.com/" title="OMNI Marketing provides effective Internet marketing and web visibility to generate quality traffic, leads, and sales. Because of the recent downturn in the economy, the market is less competitive than ever before. Now is the best time for your business to achieve top rankings and outstanding ROI.">Los Angeles Internet Marketing Company</a>
<br>OMNI Marketing provides effective Internet marketing and web visibility to generate quality traffic, leads, and sales. Because of the recent downturn in the economy, the market is less competitive than ever before. Now is the best time for your business to achieve top rankings and outstanding ROI.

On your page, the code will look like this:
Los Angeles Internet Marketing Company
OMNI Marketing provides effective Internet marketing and web visibility to generate quality traffic, leads, and sales. Because of the recent downturn in the economy, the market is less competitive than ever before. Now is the best time for your business to achieve top rankings and outstanding ROI.

If you'd like the description of your site modified, the category
changed, or if you have any other cross-promotion ideas, feel free to
email us.

Please link to us using the code above,and let us know where we can find the link.

Best regards,
Gord
optitrex1@...

This is NOT SPAM -- this is a one-time reciprocal link request. We
have NO INTENTION to email you again. You can also reply to this email
with REMOVE in the subject line to make sure we'll NEVER send you any
more e-mails in the future.

_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Newbus help

2008-01-02T09:36:40Z

On Monday 31 December 2007 11:44:59 pm Tiffany Snyder wrote:

> On Dec 31, 2007 9:52 AM, John Baldwin <jhb@...> wrote:
> >
> > On Saturday 29 December 2007 02:39:41 pm Tiffany Snyder wrote:
> > > Hi,
> > > I'm bringing up a system with FreeBSD-6.2 that has 2 Host Bridges. 1
> > > host-PCI and the other is host-Hypertransport bridge. Currently only
> > > the host-PCI bridge gets recognized and cleanly attaches all the
> > > devices underneath it. The questions are;
> > > (1) Can you tell or point to a piece of code that adds a second host
> > > bridge? I assume this get added as a child of nexus
> > > (2) How do I go about defining bus methods for the host-HT bridge and
> > > automatically enabling the newbus system to probe and attach child
> > > devices and bridges below it? Again, pointer to example code is
> > > welcome.
> >
> > Are you using ACPI or a custom BIOS of some sort?
>
> Custom BIOS that only sets up the PCI host bridge. SW has to manually
> bootstrap the HT host bridge, attach and manage resources for all the
> children below it.

Ok. Right now that's not easy to do. I'm working on changing x86 to have a
logical platform device to handle the non-ACPI and non-PC-AT cases. Probably
this will show up as each platform having its own nexus(4) driver and you can
then enumerate platform-specific devices like PCI host bridges in your nexus
driver's attach routine. Right now what you'd have to do is create your
own 'foo0' that attaches to nexus0 and overrides acpi0 and legacy0
(unfortunately that means hacking legacy0 as it only checks for acpi0
currently).

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Newbus help

2007-12-31T21:31:15Z

In message: <b63e753b0712312044o1528e57dsa8aad1ce8c952d71@...>
"Tiffany Snyder" <tiffany.snyder@...> writes:
: On Dec 31, 2007 9:52 AM, John Baldwin <jhb@...> wrote:
: >
: > On Saturday 29 December 2007 02:39:41 pm Tiffany Snyder wrote:
: > > Hi,
: > > I'm bringing up a system with FreeBSD-6.2 that has 2 Host Bridges. 1
: > > host-PCI and the other is host-Hypertransport bridge. Currently only
: > > the host-PCI bridge gets recognized and cleanly attaches all the
: > > devices underneath it. The questions are;
: > > (1) Can you tell or point to a piece of code that adds a second host
: > > bridge? I assume this get added as a child of nexus
: > > (2) How do I go about defining bus methods for the host-HT bridge and
: > > automatically enabling the newbus system to probe and attach child
: > > devices and bridges below it? Again, pointer to example code is
: > > welcome.
: >
: > Are you using ACPI or a custom BIOS of some sort?
:
: Custom BIOS that only sets up the PCI host bridge. SW has to manually
: bootstrap the HT host bridge, attach and manage resources for all the
: children below it.

FreeBSD's pci bridge driver doesn't do all the things needed to do
this. We'd be happy to help you add them to the driver. It is
something that's been needed for a while, and blocking on another
long-term feature, but something that could be done without it
(although less eloquently).

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Newbus help

2007-12-31T20:44:59Z

On Dec 31, 2007 9:52 AM, John Baldwin <jhb@...> wrote:

>
> On Saturday 29 December 2007 02:39:41 pm Tiffany Snyder wrote:
> > Hi,
> > I'm bringing up a system with FreeBSD-6.2 that has 2 Host Bridges. 1
> > host-PCI and the other is host-Hypertransport bridge. Currently only
> > the host-PCI bridge gets recognized and cleanly attaches all the
> > devices underneath it. The questions are;
> > (1) Can you tell or point to a piece of code that adds a second host
> > bridge? I assume this get added as a child of nexus
> > (2) How do I go about defining bus methods for the host-HT bridge and
> > automatically enabling the newbus system to probe and attach child
> > devices and bridges below it? Again, pointer to example code is
> > welcome.
>
> Are you using ACPI or a custom BIOS of some sort?

Custom BIOS that only sets up the PCI host bridge. SW has to manually
bootstrap the HT host bridge, attach and manage resources for all the
children below it.

Thanks,

Tiffany Snyder
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Newbus help

2007-12-31T09:52:05Z

On Saturday 29 December 2007 02:39:41 pm Tiffany Snyder wrote:

> Hi,
> I'm bringing up a system with FreeBSD-6.2 that has 2 Host Bridges. 1
> host-PCI and the other is host-Hypertransport bridge. Currently only
> the host-PCI bridge gets recognized and cleanly attaches all the
> devices underneath it. The questions are;
> (1) Can you tell or point to a piece of code that adds a second host
> bridge? I assume this get added as a child of nexus
> (2) How do I go about defining bus methods for the host-HT bridge and
> automatically enabling the newbus system to probe and attach child
> devices and bridges below it? Again, pointer to example code is
> welcome.

Are you using ACPI or a custom BIOS of some sort?

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Newbus help

2007-12-29T11:39:41Z

Hi,
I'm bringing up a system with FreeBSD-6.2 that has 2 Host Bridges. 1
host-PCI and the other is host-Hypertransport bridge. Currently only
the host-PCI bridge gets recognized and cleanly attaches all the
devices underneath it. The questions are;
(1) Can you tell or point to a piece of code that adds a second host
bridge? I assume this get added as a child of nexus
(2) How do I go about defining bus methods for the host-HT bridge and
automatically enabling the newbus system to probe and attach child
devices and bridges below it? Again, pointer to example code is
welcome.

Thanks,

Tiffany Snyder.
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

iicbus ivars and BUS_ADD_CHILD

2007-11-06T14:22:27Z

Hi everyone,

I've been looking over the 7.0 iicbus code, and I see that the iicbus
driver now uses an ivar to store the address for each child device
(cool!). The ivar is malloc'ed in the iicbus implementation of
BUS_ADD_CHILD, but it doesn't ever appear to be freed. And bus_if.m
doesn't appear to contain a reciprocal for BUS_ADD_CHILD (e.g.
BUS_DELETE_CHILD) that would take care of bus-specific cleanup. Are
ivars just leaked right now when device_delete_child() is called on
the child device, or is the caller of device_delete_child() expected
to free them?

Thanks,
Jason
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

cites

2006-11-18T09:29:50Z

Stocks Quotes in attachement

Toward Muslim minorities was drop Auto of driver in two.
Nikhat a Kazmitimes another is film promotes in sanctity in marriage a affairs of arent?
Smith spots of chink armoury.
Ltte Fresh violence sri kills.
Corus and above Tatacorus set merger deadline is match in Mittal or?
Flow tops help.
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Help with "mono_time"

2006-11-08T22:07:48Z

Hello,
I am working on FreeBSD 4.10.
I am looking at /net/hostcache.c.
The functions hc_insert(), hc_timeout, hc_rele and
hc_timeout access a structure called mono_time.
The search for this structure did not yield much
information.
I couldn't find the declaration of this particular
structure.(in FreeBSD6 its declared in
sys/netinet6/ipsec.c)

Am I missing something?

Thanks,
Alok.

____________________________________________________________________________________
Sponsored Link

Degrees online in as fast as 1 Yr - MBA, Bachelor's, Master's, Associate
Click now to apply http://yahoo.degrees.info
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Working on new-bus

2006-10-29T04:29:34Z

Hi,
I would like to know if there are open items about new-bus, where I can find
documentation in order to improve it, etc.

Thanks for the help!
Mark
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Network device driver issues.

2006-10-26T13:04:16Z

In message: <20061026132453.48510.qmail@...>
Alok Barsode <namaskar_alok@...> writes:
: Hello,
: I am porting freeBSD 4.10 to a embedded board.
: The board has 2 Three speed Ethernet Controller and a
: Cicada PHY.
: I have implemented a pseudo-bus (called mpcbus) which
: attaches itself to nexus.
: i plan to attach all the devices to the mpcbus. (i
: will be calling the IDENTIFY function for each
: device-driver).All the devices are memory
: mapped.
: Now i have 2 TSEC(Three-Speed Ethernet Controller)on
: the board(say TSEC0 and TSEC1).
: During the IDENTIFY routine, should the function
: BUS_ADD_CHILD() called twice ,once for each TSEC?

Yes, that would work. Actaully, you need to write a more real bus
that adds the children, but short of that, calling bus_add_child would
be a short-term workaround.

: I also dont what the PHY to be configured sepatately.
: (I right now dont want any "mii" stuff) I will
: configure the PHY manually. is this fine
: with the freeBSD point of view?

: I dont understand the
: struct xxx_mii_frame.
: i am looking at the National Semiconductor
: DP83820/DP83821 gigabit
: ethernet driver (i.e /dev/nge/if_nge.c)
:
: The frame structure is:
: struct nge_mii_frame {
: u_int8_t mii_stdelim;
: u_int8_t mii_opcode;
: u_int8_t mii_phyaddr;
: u_int8_t mii_regaddr;
: u_int8_t mii_turnaround;
: u_int16_t mii_data;
: };All the drivers use this kind of frame structure.
: Is this a generic one? how does one use it?

That looks like it might be left over from ports to other OSes. What
you are seeing in the nge driver is that it is reading/writing the
registers and doing the transactions in a rather long way. It is best
viewed as bitbanging the information out.

: is there a simple driver i can look at? or a simple
: tutorial on network drivers?
: the National Semiconductor driver is a bit complex.

Generally, one just lets the MII bus do its thing. If you look at the
if_ate driver, you can see this in operation:

#include <dev/mii/mii.h>
#include <dev/mii/miivar.h>
...
#include "miibus_if.h"
...
/* in softc */
device_t miibus; /* My child miibus */
...

after allocating the ifp:
if (mii_phy_probe(dev, &sc->miibus, ate_ifmedia_upd, ate_ifmedia_sts)) {
device_printf(dev, "Cannot find my PHY.\n");
err = ENXIO;
goto out;
}
...
/*
* Change media according to request.
*/
static int
ate_ifmedia_upd(struct ifnet *ifp)
{
struct ate_softc *sc = ifp->if_softc;
struct mii_data *mii;

mii = device_get_softc(sc->miibus);
ATE_LOCK(sc);
mii_mediachg(mii);
ATE_UNLOCK(sc);
return (0);
}

/*
* Notify the world which media we're using.
*/
static void
ate_ifmedia_sts(struct ifnet *ifp, struct ifmediareq *ifmr)
{
struct ate_softc *sc = ifp->if_softc;
struct mii_data *mii;

mii = device_get_softc(sc->miibus);
ATE_LOCK(sc);
mii_pollstat(mii);
ifmr->ifm_active = mii->mii_media_active;
ifmr->ifm_status = mii->mii_media_status;
ATE_UNLOCK(sc);
}

static void
ate_tick(void *xsc)
{
struct ate_softc *sc = xsc;
struct mii_data *mii;
int active;

/*
* The KB920x boot loader tests ETH_SR & ETH_SR_LINK and will ask
* the MII if there's a link if this bit is clear. Not sure if we
* should do the same thing here or not.
*/
ATE_ASSERT_LOCKED(sc);
if (sc->miibus != NULL) {
mii = device_get_softc(sc->miibus);
active = mii->mii_media_active;
mii_tick(mii);
if (mii->mii_media_status & IFM_ACTIVE &&
active != mii->mii_media_active) {
/*
* The speed and full/half-duplex state needs
* to be reflected in the ETH_CFG register, it
* seems.
*/
if (IFM_SUBTYPE(mii->mii_media_active) == IFM_10_T)
WR4(sc, ETH_CFG, RD4(sc, ETH_CFG) &
~ETH_CFG_SPD);
else
WR4(sc, ETH_CFG, RD4(sc, ETH_CFG) |
ETH_CFG_SPD);
if (mii->mii_media_active & IFM_FDX)
WR4(sc, ETH_CFG, RD4(sc, ETH_CFG) |
ETH_CFG_FD);
else
WR4(sc, ETH_CFG, RD4(sc, ETH_CFG) &
~ETH_CFG_FD);
}
}
...
/*
* Schedule another timeout one second from now.
*/
callout_reset(&sc->tick_ch, hz, ate_tick, sc);
}

At the end of the if_init routine, you need to start the ticker:

callout_reset(&sc->tick_ch, hz, ate_tick, sc);

You also need to implement the read/write regitser stuff

Add this to your device's method table:

/* MII interface */
DEVMETHOD(miibus_readreg, ate_miibus_readreg),
DEVMETHOD(miibus_writereg, ate_miibus_writereg),

For comparison, here's the ate read/write routines:

/*
* MII bus support routines.
*/
static int
ate_miibus_readreg(device_t dev, int phy, int reg)
{
struct ate_softc *sc;
int val;

/*
* XXX if we implement agressive power savings, then we need
* XXX to make sure that the clock to the emac is on here
*/

if (phy != 0)
return (0xffff);
sc = device_get_softc(dev);
DELAY(1); /* Hangs w/o this delay really 30.5us atm */
WR4(sc, ETH_MAN, ETH_MAN_REG_RD(phy, reg));
while ((RD4(sc, ETH_SR) & ETH_SR_IDLE) == 0)
continue;
val = RD4(sc, ETH_MAN) & ETH_MAN_VALUE_MASK;

return (val);
}

static void
ate_miibus_writereg(device_t dev, int phy, int reg, int data)
{
struct ate_softc *sc;

/*
* XXX if we implement agressive power savings, then we need
* XXX to make sure that the clock to the emac is on here
*/

sc = device_get_softc(dev);
WR4(sc, ETH_MAN, ETH_MAN_REG_WR(phy, reg, data));
while ((RD4(sc, ETH_SR) & ETH_SR_IDLE) == 0)
continue;
return;
}

The ate hardware does the bit-banging for you...

FreeBSD doesn't directly program the PHY. Your driver still needs to
do that, as illustrated above. This just takes the drudgery out of
it.

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Network device driver issues.

2006-10-26T07:24:53Z

Hello,
I am porting freeBSD 4.10 to a embedded board.
The board has 2 Three speed Ethernet Controller and a
Cicada PHY.
I have implemented a pseudo-bus (called mpcbus) which
attaches itself to nexus.
i plan to attach all the devices to the mpcbus. (i
will be calling the IDENTIFY function for each
device-driver).All the devices are memory
mapped.
Now i have 2 TSEC(Three-Speed Ethernet Controller)on
the board(say TSEC0 and TSEC1).
During the IDENTIFY routine, should the function
BUS_ADD_CHILD() called twice ,once for each TSEC?

I also dont what the PHY to be configured sepatately.
(I right now dont want any "mii" stuff) I will
configure the PHY manually. is this fine
with the freeBSD point of view? I dont understand the
struct xxx_mii_frame.
i am looking at the National Semiconductor
DP83820/DP83821 gigabit
ethernet driver (i.e /dev/nge/if_nge.c)

The frame structure is:
struct nge_mii_frame {
u_int8_t mii_stdelim;
u_int8_t mii_opcode;
u_int8_t mii_phyaddr;
u_int8_t mii_regaddr;
u_int8_t mii_turnaround;
u_int16_t mii_data;
};All the drivers use this kind of frame structure.
Is this a generic one? how does one use it?

is there a simple driver i can look at? or a simple
tutorial on network drivers?
the National Semiconductor driver is a bit complex.

Thanks,
alok.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Device enumeration process

2006-10-06T09:42:31Z

In message: <20061006073434.71730.qmail@...>
Alok Barsode <namaskar_alok@...> writes:
: Thanks for ur earliers replies. They helped me a lot
: in understanding the newbus architecture.
: I am involved in a freeBSD port to a freescale board.

Cool! Remind me: is the freescale an arm design or a Power PC one?

: When i/o configuration is in progress during startup,
: are the drivers for specific busses alreay assosciated
: with them or the association happens at run time ?

The drivers are associated with the busses at compile time (as
extended via modules that are loaded). The assignment of specific
device nodes to drivers is done at run time.

: for example :
: when nexus is being attached to root_bus,
: the method devclass_find_internal("nexus", 0, TRUE) is
: invoked(in method make_device).Now does a nexus
: devclass already exist ( it is created through the
: macro DRIVER_MODULE(nexus, root, nexus_driver,
: nexus_devclass, 0, 0);) or it is created at runtime ?
:
: if it is created at runtime how the nexus_driver get
: assciated with nexus?

nexus_driver gets associated with nexus here:

/*
* Determine i/o configuration for a machine.
*/
static void
configure_first(dummy)
void *dummy;
{

/* nexus0 is the top of the i386 device tree */
device_add_child(root_bus, "nexus", 0);
}

at least tenatively associated. configure_first is run via the
SYSINIT at SI_SUB_CONFIGURE as the first thing. In fact, all the
autoconf look similar in this respect. The arm one does the same
thing.

If you look at sys/arm/at91/at91.c, you'll see code:

static void
at91_identify(driver_t *drv, device_t parent)
{

BUS_ADD_CHILD(parent, 0, "atmelarm", 0);
}

which is how the atmelbus gets added to nexus. Again, the atmelbus is
about the best example I can easily find in the tree...

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Device enumeration process

2006-10-06T01:34:34Z

Hi,
Thanks for ur earliers replies. They helped me a lot
in understanding the newbus architecture.
I am involved in a freeBSD port to a freescale board.

I still had a few doubts:
I am looking at the autoconf.c file for the i386
architecture.

When i/o configuration is in progress during startup,
are the drivers for specific busses alreay assosciated
with them or the association happens at run time ?
for example :
when nexus is being attached to root_bus,
the method devclass_find_internal("nexus", 0, TRUE) is
invoked(in method make_device).Now does a nexus
devclass already exist ( it is created through the
macro DRIVER_MODULE(nexus, root, nexus_driver,
nexus_devclass, 0, 0);) or it is created at runtime ?

if it is created at runtime how the nexus_driver get
assciated with nexus?

Thanks,
Alok.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Properly managing sub-allocations

2006-10-02T15:08:12Z

In message: <200610021620.44185.john@...>
John Baldwin <john@...> writes:
: On Monday 02 October 2006 15:42, M. Warner Losh wrote:
: > In message: <200610021403.50339.john@...>
: > John Baldwin <john@...> writes:
: > : > However, this may break some existing drivers that allocate a BAR,
: > : > peek at its type and then either activate it or allocate another
: > : > BAR... The TAG is valid, but the handle isn't.
: > :
: > : They generally peak at the BAR register itself though, not the value of
: > : rman_get_bustag() though, right?
: >
: > Some do, some get the resource and look at it. There's a lot of
: > variance here. Do you put knowledge of how to decode PCI bars into
: > every driver, or do you let the pci bus take care of it? Since the
: > knowledge is nearly trivial, different people decide differenly. It
: > is still a technique that has been used, and you'll need to be careful
: > to make sure you don't break anything. After all, 0 is a valid I/O
: > tag and it is also the default value...
:
: Err, how can code examine the actual bus tag value of a non-active resource?
: By definition it's set an opaque MD value. You can't compare it against
: SYS_RES_MEMORY for example. On i386 systems it happens to be an int, on some
: other systems (alpha maybe?) I think it can be a pointer to a structure of
: function pointers for the different bus space operations. I don't think any
: MI code should ever be examining the bus tag or handle except to pass them as
: opaque parameters to bus_space_*().

Actually, you are right. I'm confusing success/failure of allocating
a I/O and/or Memory bar with this...

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Properly managing sub-allocations

2006-10-02T14:20:43Z

On Monday 02 October 2006 15:42, M. Warner Losh wrote:

> In message: <200610021403.50339.john@...>
> John Baldwin <john@...> writes:
> : > However, this may break some existing drivers that allocate a BAR,
> : > peek at its type and then either activate it or allocate another
> : > BAR... The TAG is valid, but the handle isn't.
> :
> : They generally peak at the BAR register itself though, not the value of
> : rman_get_bustag() though, right?
>
> Some do, some get the resource and look at it. There's a lot of
> variance here. Do you put knowledge of how to decode PCI bars into
> every driver, or do you let the pci bus take care of it? Since the
> knowledge is nearly trivial, different people decide differenly. It
> is still a technique that has been used, and you'll need to be careful
> to make sure you don't break anything. After all, 0 is a valid I/O
> tag and it is also the default value...

Err, how can code examine the actual bus tag value of a non-active resource?
By definition it's set an opaque MD value. You can't compare it against
SYS_RES_MEMORY for example. On i386 systems it happens to be an int, on some
other systems (alpha maybe?) I think it can be a pointer to a structure of
function pointers for the different bus space operations. I don't think any
MI code should ever be examining the bus tag or handle except to pass them as
opaque parameters to bus_space_*().

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Properly managing sub-allocations

2006-10-02T13:42:04Z

In message: <200610021403.50339.john@...>
John Baldwin <john@...> writes:
: > However, this may break some existing drivers that allocate a BAR,
: > peek at its type and then either activate it or allocate another
: > BAR... The TAG is valid, but the handle isn't.
:
: They generally peak at the BAR register itself though, not the value of
: rman_get_bustag() though, right?

Some do, some get the resource and look at it. There's a lot of
variance here. Do you put knowledge of how to decode PCI bars into
every driver, or do you let the pci bus take care of it? Since the
knowledge is nearly trivial, different people decide differenly. It
is still a technique that has been used, and you'll need to be careful
to make sure you don't break anything. After all, 0 is a valid I/O
tag and it is also the default value...

: > This specific problem will never happen in pc98, since there are no
: > ACPI pc98 machines and can never be.
:
: Yeah, but I can cleanup the stuff in ACPI a good bit if I can get it
: to stop peeking at the "real" resource to get the bus tag. Also, I
: think fixing this would be important for a driver that wanted to
: sub-alloc its resources out to children (like vgapci, which
: currently cheats on that).

Good point. I don't dispute this is a good thing, just that it will
solve a problem we're currently having. Given the push for embedded,
this is a problem worth solving.

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Properly managing sub-allocations

2006-10-02T12:03:50Z

On Monday 02 October 2006 13:39, M. Warner Losh wrote:
> In message: <200610021323.50997.john@...>
> John Baldwin <john@...> writes:
> : I'm trying to cleanup a few things in apci and I ran into what I think is
a
> : new-bus architecture issue. Specifically, acpi likes to allocate system
> : resource resources from its parent, and then turn around and sub-alloc
those
> : out to children. This mostly works fine except for the bus space details
of
> : the bus tag and bus handle. Currently acpi(4) just copies the tag from
the
> : corresponding resource from the parent and sets the handle to the start of
> : the resource. This just happens to work currently because i386 and amd64
use
> : the start of the resource for the handle for SYS_RES_IO and overwrite the
> : handle in nexus_activate_resource() for SYS_RES_MEMORY. This does add
some
> : ugliness though in that acpi needs to go find the parent resouce to copy
the
> : bus tag. However, it's current algorithm wouldn't work in general (PC98
> : needs to alloc bus handles, and it does so in nexus_alloc_resource() for
> : example).
> :
> : To solve this, I think we need to stop setting bus tags and handles in
> : bus_alloc_resource(). One solution might be to add a new bus method to
set
> : those for a resource, but I think the better solution would be to set the
bus
> : tags and handles in bus_activate_resource(). It already sort of does this
> : for some cases (SYS_RES_MEMORY on x86 for example) and will work with the
> : existing ACPI model (it already passes up activate_resource to the parent,
so
> : we would just have to remove the explicit setting of the bus tag and
handle).

> :
> : I actually wonder if this isn't how things are supposed to be in the first
> : place and that the current aberrations are just bugs?
>
> I think you are right. Thinking about it, you can't access the
> resources until you've activated them...
>
> However, this may break some existing drivers that allocate a BAR,
> peek at its type and then either activate it or allocate another
> BAR... The TAG is valid, but the handle isn't.

They generally peak at the BAR register itself though, not the value of
rman_get_bustag() though, right?

> This specific problem will never happen in pc98, since there are no
> ACPI pc98 machines and can never be.

Yeah, but I can cleanup the stuff in ACPI a good bit if I can get it to stop
peeking at the "real" resource to get the bus tag. Also, I think fixing this
would be important for a driver that wanted to sub-alloc its resources out to
children (like vgapci, which currently cheats on that).

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: Properly managing sub-allocations

2006-10-02T11:39:54Z

In message: <200610021323.50997.john@...>
John Baldwin <john@...> writes:
: I'm trying to cleanup a few things in apci and I ran into what I think is a
: new-bus architecture issue. Specifically, acpi likes to allocate system
: resource resources from its parent, and then turn around and sub-alloc those
: out to children. This mostly works fine except for the bus space details of
: the bus tag and bus handle. Currently acpi(4) just copies the tag from the
: corresponding resource from the parent and sets the handle to the start of
: the resource. This just happens to work currently because i386 and amd64 use
: the start of the resource for the handle for SYS_RES_IO and overwrite the
: handle in nexus_activate_resource() for SYS_RES_MEMORY. This does add some
: ugliness though in that acpi needs to go find the parent resouce to copy the
: bus tag. However, it's current algorithm wouldn't work in general (PC98
: needs to alloc bus handles, and it does so in nexus_alloc_resource() for
: example).
:
: To solve this, I think we need to stop setting bus tags and handles in
: bus_alloc_resource(). One solution might be to add a new bus method to set
: those for a resource, but I think the better solution would be to set the bus
: tags and handles in bus_activate_resource(). It already sort of does this
: for some cases (SYS_RES_MEMORY on x86 for example) and will work with the
: existing ACPI model (it already passes up activate_resource to the parent, so
: we would just have to remove the explicit setting of the bus tag and handle).
:
: I actually wonder if this isn't how things are supposed to be in the first
: place and that the current aberrations are just bugs?

I think you are right. Thinking about it, you can't access the
resources until you've activated them...

However, this may break some existing drivers that allocate a BAR,
peek at its type and then either activate it or allocate another
BAR... The TAG is valid, but the handle isn't.

This specific problem will never happen in pc98, since there are no
ACPI pc98 machines and can never be.

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Properly managing sub-allocations

2006-10-02T11:23:50Z

I'm trying to cleanup a few things in apci and I ran into what I think is a
new-bus architecture issue. Specifically, acpi likes to allocate system
resource resources from its parent, and then turn around and sub-alloc those
out to children. This mostly works fine except for the bus space details of
the bus tag and bus handle. Currently acpi(4) just copies the tag from the
corresponding resource from the parent and sets the handle to the start of
the resource. This just happens to work currently because i386 and amd64 use
the start of the resource for the handle for SYS_RES_IO and overwrite the
handle in nexus_activate_resource() for SYS_RES_MEMORY. This does add some
ugliness though in that acpi needs to go find the parent resouce to copy the
bus tag. However, it's current algorithm wouldn't work in general (PC98
needs to alloc bus handles, and it does so in nexus_alloc_resource() for
example).

To solve this, I think we need to stop setting bus tags and handles in
bus_alloc_resource(). One solution might be to add a new bus method to set
those for a resource, but I think the better solution would be to set the bus
tags and handles in bus_activate_resource(). It already sort of does this
for some cases (SYS_RES_MEMORY on x86 for example) and will work with the
existing ACPI model (it already passes up activate_resource to the parent, so
we would just have to remove the explicit setting of the bus tag and handle).

I actually wonder if this isn't how things are supposed to be in the first
place and that the current aberrations are just bugs?

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

Re: more Device enumeration

2006-09-30T12:43:34Z

In message: <20060930120043.41538.qmail@...>
Alok Barsode <namaskar_alok@...> writes:
: A question which arises is, If the kernel calls the
: probe routine (in case of PCI)for all the devices
: attached to it during bus-enumeration, whats the point
: of having the device entries in GENERIC?

Smaller kernels can be created by omitting unwanted/unneeded devices.

: does the
: bus-dependent code call the probe routine of the
: device-driver,for only those devices which are
: mentioned in GENERIC file.

Only for those modules that are loaded, would be a better way to say
it. The GENERIC file effectively specifies which modules to load by
creating a makefile that preloads them.

: I am writing a device driver for a memory mapped
: ethernet device.Does it HAVE to be attached to a
: bus?

Yes. It must be attached to a bus. The device, in hardware, is
attached to a bus by definition. The software reflects this hardware
definition and requires that you attach it to a bus. The word bus in
software just means that it has to attach somewhere.

: Its the only device I want to support(right
: now).Is it not possible to hard-code the probe-attach
: routine calls?

Not really, but creating a bus is easy.

: Can i attach it to nexus? OR Can I attach it to the
: PCI bus (though its not a PCI device) through some
: hack?

It would be better not to do that.

: This is not a i386 port hence the ISA bus is absent.
: Will i have to implement a pseudo-bus (write the
: bus-dependent code)in order to attach my device?

Ah, in that case, can you describe the hardware a little better? I'm
always curious about non-i386 ports...

For the Atmel ARM AT91RM9200 port that I've been working on, we placed
all the devices that were on the SoC part in their own bus (called
atmelarm). This bus manages the resources and attachment points for
all the devices on the atmel chip. At the moment, I've hard coded the
devices that are present and add them (see src/sys/arm/at91/at91.c for
the details). I'd like to make it even easier to create a generic-ish
bus like this, but this is the best example in the tree right now.

You could attach this to nexus, and hard wire the resources that the
ethernet driver uses. This would be a quick and dirty way of dealing
to get things rolling, but isn't very flexible or expandable and will
likely bite you in the long run...

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."