not the IRQ acknowledge, it's the acknowledge
of the user space notification.
Also note that this mechanism is not an attempt to demonstrate that to
move interrupt handlers to user space is a good thing. I wanted only to
show a way to permit to have *pseudo* interrupt handlers in user space
a
r returns
- interrupts are enabled
User space:
- signal arrive (or process is restarted)
- action is done
- notification is acknowledged (using an ioctl)
Kernel space:
- if we have other notifications to do, do one
- optionally our device interrupt generation is reenabled
--
Abramo Bagnara
alternative to queuing (user selectable) is to block
interrupt generation at hardware level in kernel space immediately
before notification.
I'm missing something?
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via E
separated from master volume. Often there is another
control that control if the two are linked.
Application may ask notification for controls changes (like the hw
volume one). This imply that an interrupt is related to this event.
--
Abramo Bagnara mailto:[EMAIL PROTECTE
rs not. Is there a reason for this or is this
> inconsistency simply a bug?
This is a bug on some architectures, I've personally fixed this on PPC
sending a patch to Cort Dougan. It has been included in 2.4.5.
I'd like you send a patch to maintainers (or perhaps to Alan).
--
Abr
Alexander Viro wrote:
>
> On Sun, 20 May 2001, Abramo Bagnara wrote:
>
> > > Face it, we _already_ have more than one side band.
> >
> > This does not imply it's necessarily a good idea.
> > We are comparing
> >
> > echo "9600" >
Alexander Viro wrote:
>
> On Sun, 20 May 2001, Abramo Bagnara wrote:
>
> > > It may have several. Which one?
> >
> > Can you explain better this?
>
> Example: console. You want to be able to pass font changes. I'm
> less than sure that putting t
trol_fd(fd);
> > If fd is something that doesn't have a control interface (say, it already
> > is a control filehandle), this returns an appropriate error code.
>
> It may have several. Which one?
Can you explain better this?
--
Abramo Bagnara mailto:[EM
Alexander Viro wrote:
>
> On Sun, 20 May 2001, Abramo Bagnara wrote:
>
> > I've just had a "so simple to risk to be stupid" idea.
> >
> > To have /proc/self/fd/N/ioctl would not have the potential to suppress
> > ioctl needs for *all* current uses
.g. fd0ctl, fd1ctl, fd2ctl, fd3ctl). write()
> to the latter passes commands. No extra syscalls needed.
I've just had a "so simple to risk to be stupid" idea.
To have /proc/self/fd/N/ioctl would not have the potential to suppress
ioctl needs for *all* current
e_ ioctl's.
However
fchdir(fd);
s = open("speed");
write(s, "19200\n", 6);
would be enough to solve the problem Pavel is pointing also without the
need to use ioctl.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unic
h such side effects.
> A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a
> no-op. Breaking that assumption is a Bad Thing(tm).
Can't this easily avoided if the needed action is not
< /dev/zero/start_nuclear_war
or
> /dev/zero/start_nuclear_war
but
echo "
Jes Sorensen wrote:
>
> >>>>> "Abramo" == Abramo Bagnara <[EMAIL PROTECTED]> writes:
>
> Abramo> "David S. Miller" wrote:
> >> One final point, I want to reiterate that I believe:
> >>
> >> foo = readl(®s-
"David S. Miller" wrote:
>
> Abramo Bagnara writes:
> > it's perfectly fine to have:
> >
> > regs = (struct reg *) ioremap(addr, size);
> > foo = readl((unsigned long)®s->bar);
> >
>
> I don't see how one can find this valid
"David S. Miller" wrote:
>
> Abramo Bagnara writes:
> > IMO this is a far less effective debugging strategy.
>
> I agree with you.
>
> But guess what driver authors are going to do? They are going to cast
> the thing left and right. And sure you can
t; An alternative is to add an fixed offset to the cookie before returning it,
> and subtract it again in {read,write}[bwl].
You understand that in this way you change a compile time warning in a
runtime error (conditioned to path reaching, not easy to interpret,
etc.)
IMO this is a far l
allowed.
The problem I see is that with the former solution nothing prevents from
to do:
regs->reg2 = 13;
That's indeed the reason to change ioremap prototype for 2.5.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +3
Linus Torvalds wrote:
>
> On Thu, 19 Apr 2001, Abramo Bagnara wrote:
> >
> > > [ Using file descriptors ]
> >
> > This would also permit:
> > - to have poll()
> > - to use mmap() to obtain the userspace area
> >
> > It would become somet
However I've a few doubts:
- choice policy for thread to wake is not selectable
- we separate shared memory area from file descriptor
- the implementation of down_try has neither been discussed nor
excluded, but I don't see how to implement it
The implementation of
d also permit:
- to have poll()
- to use mmap() to obtain the userspace area
It would become something very near to sacred Unix dogmas ;-)
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Ca
rdiff_t;
> > +typedef unsigned long __kernel_size_t;
> > +typedef long __kernel_ssize_t;
> > +typedef long __kernel_ptrdiff_t;
>
> If it doesn't matter on i386 why bother?
It helps with printf %-formats to avoid some arch specific warnings.
--
ts)
wmb();
--flag;
wmb();
... *p_flag test
++flag;
counter += delta; (first 32 bits)
counter == *p_counter test
counter += delta; (last 32 bits)
wmb();
--flag;
wmb();
Improbable but theoretically possible.
--
Abramo Bagnara
struct perfcounter {
int begin, end; /* both initialized to 0 */
u64 counter1;
u64 counter2;
};
kernel:
s->begin++;
wmb();
update performance counter(s)
wmb();
s->end++;
user:
volatile struct perfcounter *s;
do {
_end = s->end;
c1 = s->co
is solved trivially
b) is ok because server would read/write directly ioctl arguments from
client address space.
Security is a non issue here as also for kernel space driver
applications expose all their address space to driver.
--
Abramo Bagnara mailto:[EMAIL PROTEC
Alexander Viro wrote:
>
> On Wed, 7 Mar 2001, Abramo Bagnara wrote:
>
> > Alexander Viro wrote:
> > >
> > > On Wed, 7 Mar 2001, Jeremy Elson wrote:
> > >
> > > > Right now, my code looks something like this: (it might make more
> > >
releasing it soon, hopefully after I
> > resolve this performance problem. Or maybe before, if it's hard.)
>
> Ugh. Why not make that a named pipe and use zerocopy stuff for pipes?
> I.e. why bother with making it look like a character device rather than
> a FIFO?
What about ioct
).
The other huge drawback for ptrace is the impossibility to use mmap.
With older versions of Linux it was feasible to mmap /proc/PID/mem and
this was a very elegant way to do the job.
Unfortunately this feature has been dropped, but I don't know for which
reasons.
--
Abramo Bagnara
going to dust off my enhanced "bust_spinlocks"
> patch which sets a little flag when we're doing an
> oops, BUG(), panic() or die(). If the flag
> is set, printk() just punches through the lock.
IMO to treat this as an exception it's not the right solution.
A bette
g warning in printk documentation: "Note that
arguments may to be not evaluated" and hope everybody note it.
I'd prefer to rely on modern compiler smartness.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
age) and it seems to violate the principle of least surprise.
I think this point of view is easily agreeable.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALS
Before of all I want to publicly apologize with Richard as never my
intention was to exacerbate him.
>
> On Sun, Dec 10, 2000 at 10:23:20PM +0100, Abramo Bagnara wrote:
> > asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is
> > defined, otherwise it uses
Richard Henderson wrote:
>
> On Sun, Dec 10, 2000 at 08:04:07PM +0100, Abramo Bagnara wrote:
> > ... the only missing things from core_t2.h are some defines to
> > permit to it to work when CONFIG_ALPHA_T2 is defined.
>
> Have you tried it? I did. It works fine.
>
Richard Henderson wrote:
>
> On Sun, Dec 10, 2000 at 10:40:12AM +0100, Abramo Bagnara wrote:
> > And this would be the only core_*.h files where this intention is
> > expressed?
>
> Not at all. See core_lca.h, jensen.h, core_cia.h, core_mcpcia.h.
I think you're c
Richard Henderson wrote:
>
> On Sat, Dec 09, 2000 at 09:43:00AM +0100, Abramo Bagnara wrote:
> > alpha-mb-2.4.diff add missing defines from core_t2.h for non generic
> > kernel (against 2.4.0test11)
>
> These are not "missing". They are intentionally not pr
etime this is not a perfect world ;-)
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE
read[bwlq] while 2.2 don't.
Who's right?
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project ishttp://www.alsa-project.org
sp
racting one from
> the result, in order to derive the maximal allowable value, might work.
> I do not think that we have anything with non-8 bit bytes yet.
>
I think it's time to provide SIZE_MAX and SSIZE_MAX along with
size_t/ssize_t typedefs.
--
Abramo Bagnara
unsigned long rmask;
void (*event_fn)(struct event *event);
is a far better solution (more type safe, more descriptive).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Via Emilia Interna, 140 Phone: +39.0546.656023
48014 Castel Bologn
gt;> 56) )); \
> +})
Isn't this more efficient?
n = (x>>32) | (x<<32);
n = ((n & 0xLL)<<16) | (n & 0x00000000LL)>>16;
n = ((n & 0x00ff00ff00ff00ffLL)<<8) | (n & 0xff00ff00ff00ff00LL)>>8;
6 shift
4 and
3 or
i
milies.
Probably one of your gnomes knows it (I hope that this specific gnome is
not in hibernation in this season :-)
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Via Emilia Interna, 140 Phone: +39.0546.656023
48014 Castel Bolognese (RA) - I
Linus Torvalds wrote:
>
> On Thu, 21 Sep 2000, Abramo Bagnara wrote:
> >
> > In ALSA we use the return value from ioctl as a simple way to return a
> > positive number to user space (if the return value is less than 0 we got
> > error, of course)
>
> Looks f
r to ioctl call.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Via Emilia Interna, 140 Phone: +39.0546.656023
48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023
ALSA project ishttp://www.alsa-project.org
sponsored by SuS
42 matches
Mail list logo
