On Mon, Aug 12, 2013 at 10:42:03AM -0700, Andy Lutomirski wrote:
> You'll have the same problem that O_TMPFILE had: the kernel currently
> ignores unrecognized flags. I wonder if it's time to add a new syscall
> (or syscalls) with more sensible semantics.
That's not a problem here. In fact, in th
[cc: linux-api]
On 08/02/2013 07:48 PM, Rich Felker wrote:
> Hi,
>
> At present, one of the few interface-level conformance issues for
> Linux against POSIX 2008 is lack of O_SEARCH and O_EXEC. I am trying
> to get full, conforming support for them both into musl libc (for
> which I am the maint
Hi,
At present, one of the few interface-level conformance issues for
Linux against POSIX 2008 is lack of O_SEARCH and O_EXEC. I am trying
to get full, conforming support for them both into musl libc (for
which I am the maintainer) and glibc (see the libc-alpha post[1]).
At this point, I believe i
On Thu, Jun 20, 2013 at 02:42:04PM +0100, Steve Twiss wrote:
> From: Steve Twiss
>
> The following describes the driver DA9210 from Dialog Semiconductor Ltd.
>
> This is a request for comment relating to the Dialog DA9210 driver.
> The patches have been made relative to the following kernel vers
From: Steve Twiss
The following describes the driver DA9210 from Dialog Semiconductor Ltd.
This is a request for comment relating to the Dialog DA9210 driver.
The patches have been made relative to the following kernel version:
linux-next next-20130620
This driver is for the Dialog DA9210 Mult
Ollie Wild <[EMAIL PROTECTED]> wrote:
> - I haven't tested this on a NOMMU architecture. Could someone please
> validate this?
There are a number of potential problems with NOMMU:
(1) The argument data is copied twice (once into kernel memory and once out
of kernel memory).
(2) The perm
On Thu, Jul 19, 2001 at 07:33:02PM +0200, Andi Kleen wrote:
> Cornel Ciocirlan <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I was thinking of starting a project to implement a Cisco-like
> > "NetFlow" architecture for Linux. This would be relevant for edge routers
> > and/or network monitoring
Cornel Ciocirlan <[EMAIL PROTECTED]> writes:
> Hi,
>
> I was thinking of starting a project to implement a Cisco-like
> "NetFlow" architecture for Linux. This would be relevant for edge routers
> and/or network monitoring devices.
Linux 2.1+ already has such a cache in form of the rtcache si
On Thu, Jul 19, 2001 at 06:44:52PM +0300, Cornel Ciocirlan wrote:
> What this would do is keep a "cache" of all the "flows" that are passing
> through the system; a flow is defined as the set of packets that have the
> same headers - or header fields. For example we could choose "ip source,
> ip
Cornel Ciocirlan <[EMAIL PROTECTED]> ecrit :
[heavy linux networking rewrite in sight]
> Is it useful at all ? Point b) above could be implemented in userspace
> (Actually I've done a basic skeleton a while ago). Are the others worth
> the trouble ?
>
> What do you gurus think ?
* Are you sure o
++ 19/07/01 18:44 +0300 - Cornel Ciocirlan:
> a) more efficient packet filtering. After a cache entry is created for a
> flow, we apply the ACLs for the packet and associate the action with the
> flow. All subsequent packets belonging to the same flow will be
> dropped/accepted without re-appying
Hi,
I was thinking of starting a project to implement a Cisco-like
"NetFlow" architecture for Linux. This would be relevant for edge routers
and/or network monitoring devices.
What this would do is keep a "cache" of all the "flows" that are passing
through the system; a flow is defined as the
There's a new update of the above thesis on the link:
http://www.student.hig.se/~na98csa/linux/
and a postscript file at:
http://www.student.hig.se/~na98csa/linux/xjobb.ps
I would appreciate help on filling in the empty spaces
on Linux and IRIX. Do also please provide a reference
to where the
Hi!
I'm looking for some help on reviewing my thesis about
comparing the kernel functions/features in Linux,
HP-UX, Solaris, IRIX, AIX, and Tru64 UNIX.
I would appreciate if you also could point out some
other features that I should add to my list (in the
tables, on page 25-28 on the postscript f
On Fri, 10 Nov 2000, Brian Gerst wrote:
> > The datasheets are somewhat confusing, as it doesn't mention bit 10
> > at all, just an oversized box for bit 11.
> The Athlons support sysenter and syscall, but the K6's only support
> syscall. The earlier version of syscall (bit 10) is undocumented b
[EMAIL PROTECTED] wrote:
>
> On Fri, 10 Nov 2000, Brian Gerst wrote:
>
> > > features: fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
> >
> > The K6's don't support sysenter/sysexit.
>
> The K6 datasheets suggests otherwise.
> Some models seem to have sysenter/sysexit, whilst othe
On Fri, 10 Nov 2000, H. Peter Anvin wrote:
> > And where does sysenter/sysexit fit in?
> sysenter/sysexit is the "sep" feature.
Ah, of course.
*slaps head*
regards,
davej.
--
| Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej
| SuSE Labs
-
To unsubscribe from this list: send the li
[EMAIL PROTECTED] wrote:
> On Fri, 10 Nov 2000, Brian Gerst wrote:
>
> > > features: fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
> >
> > The K6's don't support sysenter/sysexit.
>
> The K6 datasheets suggests otherwise.
> Some models seem to have sysenter/sysexit, whilst others
On Fri, 10 Nov 2000, Brian Gerst wrote:
> > features: fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
>
> The K6's don't support sysenter/sysexit.
The K6 datasheets suggests otherwise.
Some models seem to have sysenter/sysexit, whilst others have
syscall/sysret. No model seems to h
On Fri, 10 Nov 2000, H. Peter Anvin wrote:
> That is actually correct -- the K6-2 doesn't actually have mtrr and sep,
> but has syscall and k6_mtrr instead (the stepping bug causes k6_mtrr not
> to show up.) Part of the bugginess of the old system was using one flag
> for multiple purposes. Thi
[EMAIL PROTECTED] wrote:
>
> Hi hpa,
>
> First test, the AMD K6-2.
>
> Also, look at the feature flags:
> before:
> flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
>
> after:
> features: fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
>
> Note, I lost MTRR
[EMAIL PROTECTED] wrote:
>
> Hi hpa,
>
> First test, the AMD K6-2.
>
> Before your patch..
> cpu family : 5
> model : 8
> stepping: 12
>
> After..
>
> cpu family : 5
> model : 8
> stepping: 4
>
> L
Hi hpa,
First test, the AMD K6-2.
Before your patch..
cpu family : 5
model : 8
stepping: 12
After..
cpu family : 5
model : 8
stepping: 4
Line 1826 of setup.c
c->x86_mask = tfms & 7;
Shoul
Hi guys,
I wanted to give you a preview of the CPUID revision patch; it is not
100% ready yet in that (a) it still has a bunch of debugging printk() and
(b) I haven't ported over mtrr.c yet.
This code took a lot longer to write than I had expected, mostly because
I kept running into various form
24 matches
Mail list logo
