el.phoenix@gmail.com wrote:
> I propose making a new sub-group under this heading for the
> device-driver writers across embedded platforms especially for those
> who find writing the lowest physical layer (where hardware meets the
> software ) the most interesting aspect of the product development.

Any particular OS in mind?

Paul Burke

el.phoenix@gmail.com wrote:

>Casey does have a valid point in there as do most of you ; maybe seeing
>everything in black&white and micro-classification is not such a good
>idea after all - but I would prefer having a loose confederation of
>programmers specializing in  hardware programming in C - if anyone can
>point out existing groups which though not devoted to device-drivers do
>have a high volume of software issues closely related to hardware -
>preferably on NoOS platforms - which deal with ISR issues ; buffer
>management fot real-time data- flow etc.- it would indeed be very
>helpful.

Comp.arch.embedded is an appropriate forum for such topics.  The volume
may not be what you would like, but creating a new group is not likely to
gnerate additional volume.  A far better reason to create a new group is
because the existing volume warrants it.

So, start talking about close-to-the-hardware coding here and, if such
discussions overwhelm the group you may then have a valid case for a new
group.

-- 
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
          mkesti@gv.net            |          - The Who, Bargain

Casey does have a valid point in there as do most of you ; maybe seeing
everything in black&white and micro-classification is not such a good
idea after all - but I would prefer having a loose confederation of
programmers specializing in  hardware programming in C - if anyone can
point out existing groups which though not devoted to device-drivers do
have a high volume of software issues closely related to hardware -
preferably on NoOS platforms - which deal with ISR issues ; buffer
management fot real-time data- flow etc.- it would indeed be very
helpful.
K V

Casey does have a valid point in there as do most of you ; maybe seeing
everything in black&white and micro-classification is not such a good
idea after all - but I would prefer having a loose confederation of
programmers specializing in  hardware programming in C - if anyone can
point out existing groups which though not devoted to device-drivers do
have a high volume of software issues closely related to hardware -
preferably on NoOS platforms - which deal with ISR issues ; buffer
management fot real-time data- flow etc.- it would indeed be very
helpful.
K V

And I'd be one of the ones voting "no" to this. Most of this code, if
not all of it, is going to be very specific to a particular embedded
OS. This means that most of the messages in your proposed new NG belong
rightfully in the NGs for those particular OSes.

Either people will crosspost - in which case your new NG is a waste of
time, or there will be attrition out of existing NGs. Either way, you
just multiplied the number of places people have to search for
information on a specific topic.

I am interested in the device drives group ...
Its great to have a specific group like this.

<el.phoenix@gmail.com> wrote in message
news:1103880145.003991.315730@f14g2000cwb.googlegroups.com...
> I propose making a new sub-group under this heading for the
> device-driver writers across embedded platforms especially for those
> who find writing the lowest physical layer (where hardware meets the
> software ) the most interesting aspect of the product development.

To form a new group and have it accepted for listing by most ISP
administrators, you must pass through a formal proposal process starting
with a message posted to news.groups.  After much discussion (30-90 days is
typical) and drafting a formal proposal, there will be a vote in which any
interested person with usenet access can vote.  To be accepted, there must
be at least 100 YES votes, 100 more YES votes than NO votes, and the number
of YES votes must be at least twice the number of NO votes.

There are many reasons people will vote NO.  Some people vote NO every time.

Gene S. Berkowitz said
> In article <1103880145.003991.315730@f14g2000cwb.googlegroups.com>, 
> el.phoenix@gmail.com says...
> > I propose making a new sub-group under this heading for the
> > device-driver writers across embedded platforms especially for those
> > who find writing the lowest physical layer (where hardware meets the
> > software ) the most interesting aspect of the product development.
> > K V
> 
> Frankly, I think that is the true definition of embedded software,
> and a sub-group would only serve to dilute the usefulness of the group 
> as is.

And the sub-group would have a far lower base of readers.  

Ask a question about device drivers in a subgroup, and probably only 
people who are currently focussing on device drivers will see and 
perhaps respond.

As the same question here to a larger audience and you might catch the 
attention of several people who can help you from their past 
experiences.


Casey

In article <1103880145.003991.315730@f14g2000cwb.googlegroups.com>, 
el.phoenix@gmail.com says...
> I propose making a new sub-group under this heading for the
> device-driver writers across embedded platforms especially for those
> who find writing the lowest physical layer (where hardware meets the
> software ) the most interesting aspect of the product development.
> K V

Frankly, I think that is the true definition of embedded software,
and a sub-group would only serve to dilute the usefulness of the group 
as is.

--Gene

el.phoenix@gmail.com wrote:

> I propose making a new sub-group under this heading for the
> device-driver writers across embedded platforms especially for those
> who find writing the lowest physical layer (where hardware meets the
> software ) the most interesting aspect of the product development.
> K V

Sounds good.  You have my support.

Ian
-- 
Ian Bell