On Tue, Mar 13, 2007 at 12:07:26PM -0700, Stephen Hahn wrote:
> * David Edmondson <[EMAIL PROTECTED]> [2007-03-13 11:45]:
> > On Tue, Mar 13, 2007 at 11:30:20AM -0700, Stephen Hahn wrote:
> > > Although I agree that there are problems with a "give Sun hardware"
> > > policy, I am less convinced
You are the real expert here, who provides the Solaris porting of Xserver!
I just boldly provide some thoughts. I just ignored the suspend issue. I
thought we
could solve it in kernel driver without giving up the 2d part user space
driver,
like what is done for 3d. I think we are trying to rep
The 2D part does need a kernel mode driver though, for features such as
suspend-and-resume, and for getting rid of the security issues associated
with /dev/xsvc & allowing user space processes to have ring-0 access so
that the Xserver can access the hardware from user space.
Solaris & Linux are b
Hi, Douglas,
Glad to hear from you.
As for moving X drivers to kernel, I have investigated on it. We must be
aware that nowadays the display card include two functions, 2d and 3d,
the first part does not need dma, thus can be implemented in user space
conveniently, as the 3d part, it relies
* David Edmondson <[EMAIL PROTECTED]> [2007-03-13 11:45]:
> On Tue, Mar 13, 2007 at 11:30:20AM -0700, Stephen Hahn wrote:
> > Although I agree that there are problems with a "give Sun hardware"
> > policy, I am less convinced that there shouldn't be some contributor,
> > not employed by the d
Stephen Hahn wrote:
* Richard Lowe <[EMAIL PROTECTED]> [2007-03-13 11:11]:
Paul Durrant wrote:
On 3/13/07, John Plocher <[EMAIL PROTECTED]> wrote:
Paul Durrant writes:
The current ON processes are just wrong for open source.
The ON development process forces developers to look beyond
the cur
On Tue, Mar 13, 2007 at 11:30:20AM -0700, Stephen Hahn wrote:
> Although I agree that there are problems with a "give Sun hardware"
> policy, I am less convinced that there shouldn't be some contributor,
> not employed by the device manufacturer, able to test that, with the
> device install
* Richard Lowe <[EMAIL PROTECTED]> [2007-03-13 11:11]:
> Paul Durrant wrote:
> >On 3/13/07, John Plocher <[EMAIL PROTECTED]> wrote:
> >>> Paul Durrant writes:
> The current ON processes are just wrong for open source.
> >>
> >>The ON development process forces developers to look beyond
> >>the
Paul Durrant wrote:
On 3/13/07, John Plocher <[EMAIL PROTECTED]> wrote:
> Paul Durrant writes:
>>The current ON processes are just wrong for open source.
The ON development process forces developers to look beyond
the current confines of their project and understand/manage
the impact that their
On 3/13/07, John Plocher <[EMAIL PROTECTED]> wrote:
> Paul Durrant writes:
>>The current ON processes are just wrong for open source.
The ON development process forces developers to look beyond
the current confines of their project and understand/manage
the impact that their development choices
Hi Freeman,
I have seen blogs talking about the opposite direction (I recall having read
some blog entry about moving X drivers into the kernel). However, with every
new build of Solaris Express, I get some good or bad surprise. The bad ones
usually have to do with new kernel modules that don't
Paul Durrant writes:
> On 3/13/07, James Carlson <[EMAIL PROTECTED]> wrote:
> > But the underlying point here is that you don't have to go through ON
> > (there are other supported ways to integrate drivers) and you don't
> > need to create (and can't actually use) yet another consolidation to
> >
On 3/13/07, James Carlson <[EMAIL PROTECTED]> wrote:
I think even that policy is being actively debated.
Good.
But the underlying point here is that you don't have to go through ON
(there are other supported ways to integrate drivers) and you don't
need to create (and can't actually use) ye
Paul Durrant writes:
> On 3/13/07, James Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Really?
> >
> > Which processes are wrong? Should some code not have design reviews
> > and code reviews because the author makes it "open?"
> >
>
> Not at all. I'm all for design and code reviews, but submitting
On 3/13/07, James Carlson <[EMAIL PROTECTED]> wrote:
Really?
Which processes are wrong? Should some code not have design reviews
and code reviews because the author makes it "open?"
Not at all. I'm all for design and code reviews, but submitting h/w to
ON PIT as a gating factor for source i
Paul Durrant writes:
> While I was at Sun I wondered whether there should be a consolidation
> for open source drivers (a good while before Solaris itself was open
> source). The consolidation would have very lightweight integration
> rules (since the driver source would already be freely available
On 3/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>On 3/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>> Correct; I think that Sun will need to change that attitude and define
>> a process for itself in which it limits the bits of OpenSolaris it
>> ships as part of its distributi
[EMAIL PROTECTED] wrote:
How does that work with other community provided software Sun ships by
default? Why can't that model work for drivers also?
We're already using that model for x86 graphics drivers, which live
in the X consolidation instead of ON - most of the Xorg drivers we
ship are f
>On 3/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>> Correct; I think that Sun will need to change that attitude and define
>> a process for itself in which it limits the bits of OpenSolaris it
>> ships as part of its distribution *or* finds a way to "do the community
>> thing" and ship
On 3/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Correct; I think that Sun will need to change that attitude and define
a process for itself in which it limits the bits of OpenSolaris it
ships as part of its distribution *or* finds a way to "do the community
thing" and ship the drivers a
>Writing them is only part of the story; and yes, in many cases there
>is less work to do than for Linux and, with tools such as dtrace and
>mdb, the task can actually be quite straightworward.
>*Integrating* drivers into OpenSolaris is another story... To get my
>driver in, I have to arrange for
On 3/8/07, UNIX admin <[EMAIL PROTECTED]> wrote:
If anything, writing drivers for Solaris should be far easier than for Linux!
Writing them is only part of the story; and yes, in many cases there
is less work to do than for Linux and, with tools such as dtrace and
mdb, the task can actually b
Sooner or later, if you want drivers, you or someone else will have to roll up
their sleeves and dig into the DDI/DDK documentation on docs.sun.com. There is
no way around that, no matter which elaborate schemes (user-mode, la la la) one
comes up with.
How did Linux get so many drivers? Vend
UNIX admin wrote:
I am very glad to hear such a deep thought. Now
return to the original
question: with so many hardware not supported by
Solaris, what is the
solution ?
The solution is to remedy the cause (proactive) and not try to fix the effect
(reactive):
lobby the hardware vendors
> Yes that is a real argument which I agree totally.
> Here is my point of view. If I have a piece of
> hardware that does not
> work, I will try to find one driver on Internet.
> If it works, I am happy, without bothering about how
> it is implemented.
> On the other hand, if I just
> can not fi
> I am very glad to hear such a deep thought. Now
> return to the original
> question: with so many hardware not supported by
> Solaris, what is the
> solution ?
The solution is to remedy the cause (proactive) and not try to fix the effect
(reactive):
lobby the hardware vendors to support Solari
IMO, compromising on quality, scalability, or maintainability, even to
quickly get desktop hardware support equivalent to that of some
other OS, is a mistake. And it shouldn't be necessary; if there were
some way to find out which drivers that Linux has and Solaris doesn't
are the ones people want
Richard L. Hamilton wrote:
For some more cold water (not that it should stop anyone that
believes in the idea enough to do the work!), remember UDI?
Doesn't seem to have amounted to much - I haven't heard a thing
about it in 3 or 4 years, nor do I see evidence that it resulted
in a bunch of comp
UNIX admin wrote:
Hi, everyone,
I would like to start a project to enable running a
driver in usr mode
as an application.
Are you sure? What about performance, i.e. user-level vs. kernel-level?
I have a prototype for audio and no difference for the audio quality.
As the cpu utilizat
Richard L. Hamilton wrote:
For some more cold water (not that it should stop anyone that
believes in the idea enough to do the work!), remember UDI?
Doesn't seem to have amounted to much - I haven't heard a thing
about it in 3 or 4 years, nor do I see evidence that it resulted
in a bunch of compl
Thanks, Freeman. You have seconds. I'll contact you offline
to get you set up.
Eric
On Thu, 1 Mar 2007, [EMAIL PROTECTED] wrote:
Hi, everyone,
I would like to start a project to enable running a driver in usr mode as an
application.
By this way we can leverage source code from other OSes by
s/www.project.udi.org/www.projectudi.org/
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
For some more cold water (not that it should stop anyone that
believes in the idea enough to do the work!), remember UDI?
Doesn't seem to have amounted to much - I haven't heard a thing
about it in 3 or 4 years, nor do I see evidence that it resulted
in a bunch of compliant drivers being produced.
> Hi, everyone,
>
> I would like to start a project to enable running a
> driver in usr mode
> as an application.
Are you sure? What about performance, i.e. user-level vs. kernel-level?
> By this way we can leverage source code from other
> OSes by converting them
> into Solaris user applicatio
Richard L. Hamilton wrote:
>From one other OS, maybe; multiple, I doubt it, since
each OS has a slightly different framework for drivers:
the entry points (and associated semantics) they're
supposed to provide, the kernel functions they're allowed
to call, etc.
It's not always straightforward, b
>From one other OS, maybe; multiple, I doubt it, since
each OS has a slightly different framework for drivers:
the entry points (and associated semantics) they're
supposed to provide, the kernel functions they're allowed
to call, etc.
It's not always straightforward, but I'm reasonably sure a numb
36 matches
Mail list logo
