more info

more info

[Shaun Savage]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

During the load process I get

ss: loading .....
security: 5 users, 6roles, 391 types
security: 29 classes, 74171 rules
security: context root:sysadm_r:ipchains_t is invalid

Why/How is it invalid?

attached is the new ipchains.te

Shaun 

[-- Attachment #2: ipchains.te --]
[-- Type: text/plain, Size: 1194 bytes --]

#
# Authors:  Justin Smith <jsmith@mcs.drexel.edu>
#

role sysadm_t types { ipchains_t };
domain_auto_trans(sysadm_t, ipchains_exec_t, ipchains_t)

allow tripwire_t sysadm_tty_device_t:chr_file rw_file_perms;
allow tripwire_t sysadm_devpts_t:chr_file rw_file_perms;
allow tripwire_t sysadm_gph_t:fd inherit_fd_perms;
 
auditallow sysadm_t ipchains_t:process transition;
auditallow sysadm_t ipchains_exec_t:process transition;
auditallow sysadm_t ipchains_exec_t:file execute;

#
# Rules for the ipchains_t domain.
#
type ipchains_t, domain, privlog;
type ipchains_exec_t, file_type, sysadmfile, exec_type;
type ipchains_var_run_t, file_type, sysadmfile, pidfile;

domain_auto_trans(ipchains_t, insmod_exec_t, insmod_t)

domain_auto_trans(ipchains_t, ifconfig_exec_t, ifconfig_t)
file_type_auto_trans(ipchains_t, var_run_t, ipchains_var_run_t)
uses_shlib(ipchains_t)

# Inherit and use descriptors from init.
allow ipchains_t init_t:fd inherit_fd_perms;

allow ipchains_t bin_t:file { execute execute_no_trans };
allow ipchains_t ipchains_exec_t:file { execute_no_trans };
allow ipchains_t ipchains_t:capability { net_admin net_raw };
allow ipchains_t ipchains_t:rawip_socket { create setopt };

Re: more info

[Stephen Smalley]

On Wed, 16 Jan 2002, Shaun Savage wrote:

> During the load process I get
>
> ss: loading .....
> security: 5 users, 6roles, 391 types
> security: 29 classes, 74171 rules
> security: context root:sysadm_r:ipchains_t is invalid

This error is because you didn't authorize the ipchains_t domain for the
sysadm_r role, due to your typo (sysadm_t instead of sysadm_r).  From the
perspective of the security server, you just defined a new role named
sysadm_t that is authorized for ipchains_t.  Roles and types exist in
separate namespaces, so this doesn't show up as a policy compiler error.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

documentation

[Guilhem Tardy]

Hi,

I am writing an ALSA driver for a new card. I had doc for 0.5.0, but this is
outdated and so far had to do with examples in the 0.9.0beta12 distribution
(mainly dummy.c and cs4281.c). Is there any doc available otherwise?
Any hint as for what I am facing, given that my card doesn't do DMA.

What is required from my part to support memory mapping from the driver to the
application? Would this be supported through the OSS compatibility layer, too?

Thanks,
Guilhem.


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

Re: documentation

[Takashi Iwai]

At Wed, 24 Apr 2002 07:26:04 -0700 (PDT),
Guilhem Tardy wrote:
> 
> Hi,
> 
> I am writing an ALSA driver for a new card. I had doc for 0.5.0, but this is
> outdated and so far had to do with examples in the 0.9.0beta12 distribution
> (mainly dummy.c and cs4281.c). Is there any doc available otherwise?

no, unfortunately not yet.
i posted a very brief info recently on alsa-devel.
please check out the archive.


> Any hint as for what I am facing, given that my card doesn't do DMA.
 
then you have to define copy and silence ops additionally.
copy the data on user buffer to the destination in these ops.
you'll need to reschedule ocasionally to avoid too long code path.
an example is found in gus driver (gus_pcm.c).
you can also use need_resched() to check the rescheduling.


> What is required from my part to support memory mapping from the driver to the
> application? Would this be supported through the OSS compatibility layer, too?

hmm...  mmap without dma?
how do you transfer the data on buffer to hardware?

the copy and silence ops are called when write() is called (more
exactly on alsa it's ioctl) - the thread writing to the device does
actually work like DMA.  on mmap mode, there is no such one.  so you
need an extra thread (or if it's not too heavy then tasklet might be
available) anyway.


Takashi

Re: documentation

[Guilhem Tardy]

> > What is required from my part to support memory mapping from the driver
> > to the application? Would this be supported through the OSS compatibility
> > layer, too?
> 
> hmm...  mmap without dma?
> how do you transfer the data on buffer to hardware?

The card doesn't support DMA, yet. Data is transferred to/from the buffer by
the driver copying 32-bit chunks. Those buffers were allocated by the MMAP,
today through the V4Lv2 API (this is an audio+video card).

> the copy and silence ops are called when write() is called (more
> exactly on alsa it's ioctl) - the thread writing to the device does
> actually work like DMA.  on mmap mode, there is no such one.  so you
> need an extra thread (or if it's not too heavy then tasklet might be
> available) anyway.

Having checked the brief documentation you referred to
(http://www.alsa-project.org/alsa-doc/alsa-lib/), I guess using the direct
audio buffer to communicate with the device means DMA+MMAP. I would like to do
the same thing, but have the driver actually copy data to/from the device. What
do you call "mmap mode" above?

Is there any other documentation more specific to driver development?

Guilhem.


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

more info

[Guilhem Tardy]

Hi all,

Could anyone point to me a reference for the following (or explain to me
directly what is the purpose of each of those functions) in the PCM module:

	prepare:	snd_xxxx_capture_prepare,
	trigger:	snd_xxxx_trigger,
	pointer:	snd_xxxx_pointer,
	copy:		snd_xxxx_capture_copy,
	silence:	snd_xxxx_capture_silence,

Plus, what is the fifo size (e.g. on the card)?

Thanks,
Guilhem.


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

Re: more info

[Paul Davis]

>Could anyone point to me a reference for the following (or explain to me
>directly what is the purpose of each of those functions) in the PCM module:
>
>	prepare:	snd_xxxx_capture_prepare,
>	trigger:	snd_xxxx_trigger,
>	pointer:	snd_xxxx_pointer,
>	copy:		snd_xxxx_capture_copy,
>	silence:	snd_xxxx_capture_silence,

search for "prepare" and "trigger" in the archives, and you should find
takashi's basic explanation of what the functions do. then come back
and ask more specific questions. 

>Plus, what is the fifo size (e.g. on the card)?

i'm not sure its relevant for cards with DMA. can't tell you more.

--p

Re: documentation

[Takashi Iwai]

At Wed, 24 Apr 2002 12:32:26 -0700 (PDT),
Guilhem Tardy wrote:
> 
> > > What is required from my part to support memory mapping from the driver
> > > to the application? Would this be supported through the OSS compatibility
> > > layer, too?
> > 
> > hmm...  mmap without dma?
> > how do you transfer the data on buffer to hardware?
> 
> The card doesn't support DMA, yet. Data is transferred to/from the buffer by
> the driver copying 32-bit chunks. Those buffers were allocated by the MMAP,
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> today through the V4Lv2 API (this is an audio+video card).
 
how do you mean here?
the allocated buffers are mmaped to user?

> > the copy and silence ops are called when write() is called (more
> > exactly on alsa it's ioctl) - the thread writing to the device does
> > actually work like DMA.  on mmap mode, there is no such one.  so you
> > need an extra thread (or if it's not too heavy then tasklet might be
> > available) anyway.
> 
> Having checked the brief documentation you referred to
> (http://www.alsa-project.org/alsa-doc/alsa-lib/), I guess using the direct

no, i posted to alsa-devel ML, a month ago or so.
the document you read is for the user library, not for the driver.

> audio buffer to communicate with the device means DMA+MMAP. I would like to do
> the same thing, but have the driver actually copy data to/from the device. What
> do you call "mmap mode" above?

in your case, you need to copy the data on the buffer to the hw by
yourself.  then what is the merit of mmap? 
(well, it would be a bit more efficient than copy_from_user(), but
 the advantage of copy_from_user() is that you can use non-contiguous
 buffer while alsa's mmap supports, so far, only contiguous region.)

on alsa, when the program runs in the mmap mode, no read/write is
called but the data is read/written on the mmapped buffer, and the
also mmaped status is updated.  during the app writes data, DMA
transfers the data from the mmaped buffer.
that is, the thread is free from the kernel mode.


> Is there any other documentation more specific to driver development?

at least i am not aware of such documents.
check alsa-devel ML archive.


Takashi

Re: documentation

[Guilhem Tardy]

Hi,

Now, I have this new driver which manages to open/close a pcm channel whenever
one attempts to play a file with "play test.au", but complains (Sound protocol
it not compatible) with "aplay test.au". Any idea what's wrong?
Besides, I have no mixer defined (I would just to allow open/close a playback
or capture channel, no more) and wonder if it is a problem?
I am just loading the driver manually for now (insmod snd, snd-timer, snd-pcm,
...), is there any special configuration I need? How to tell the driver to
unmute?

Thanks,
Guilhem.

> > > the copy and silence ops are called when write() is called (more
> > > exactly on alsa it's ioctl) - the thread writing to the device does
> > > actually work like DMA.  on mmap mode, there is no such one.  so you
> > > need an extra thread (or if it's not too heavy then tasklet might be
> > > available) anyway.

> no, i posted to alsa-devel ML, a month ago or so.
> the document you read is for the user library, not for the driver.

> in your case, you need to copy the data on the buffer to the hw by
> yourself.  then what is the merit of mmap? 
> (well, it would be a bit more efficient than copy_from_user(), but
>  the advantage of copy_from_user() is that you can use non-contiguous
>  buffer while alsa's mmap supports, so far, only contiguous region.)

> on alsa, when the program runs in the mmap mode, no read/write is
> called but the data is read/written on the mmapped buffer, and the
> also mmaped status is updated.  during the app writes data, DMA
> transfers the data from the mmaped buffer.
> that is, the thread is free from the kernel mode.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: documentation

[Paul Davis]

>Hi,
>
>Now, I have this new driver which manages to open/close a pcm channel whenever
>one attempts to play a file with "play test.au", but complains (Sound protocol
>it not compatible) with "aplay test.au". Any idea what's wrong?
>Besides, I have no mixer defined (I would just to allow open/close a playback
>or capture channel, no more) and wonder if it is a problem?
>I am just loading the driver manually for now (insmod snd, snd-timer, snd-pcm,
>...), is there any special configuration I need? How to tell the driver to
>unmute?

sounds as if you have the wrong version of aplay installed (relative
to the version of alsa-lib and alsa-driver)

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: documentation

[Takashi Iwai]

Hi,

At Fri, 3 May 2002 09:11:33 -0700 (PDT),
Guilhem Tardy wrote:
> 
> Hi,
> 
> Now, I have this new driver which manages to open/close a pcm
> channel whenever one attempts to play a file with "play test.au",
> but complains (Sound protocol it not compatible) with "aplay
> test.au". Any idea what's wrong? 

this error happens usually when an older version of alsa-lib /
alsa-utils are installed.  please check the version of alsa-lib.
(must be linked to libasound.so.2)


> Besides, I have no mixer defined (I would just to allow open/close a
> playback or capture channel, no more) and wonder if it is a problem?

no.  you can initialize the mixer part even in open of pcm callbacks,
if it's not necessarily configurable.


> I am just loading the driver manually for now (insmod snd,
> snd-timer, snd-pcm,  ...), is there any special configuration I
> need? How to tell the driver to  unmute?

generally modprobe resolves the dependency, i.e. just load the
top-level module like

	# modprobe snd-yourdriver

then all low-level drivers will be loaded.

well, unmute...?  if there is no mixer, the device should be always
unmuted, or as mentioned above, toggle mute/unmute at open/close.

anyway, i would advise you to post your working code (or its URL) to
alsa-devel ML, so that other developers can take a look.


ciao,

Takashi

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net