Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Jan 2015 08:34:32 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Andrew Turner <andrew@fubar.geek.nz>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: interrupt framework
Message-ID:  <6E33C7B5-F784-4604-9F09-9FEDB1EFBE56@bsdimp.com>
In-Reply-To: <20150116120315.7f343f66@bender.lan>
References:  <CAFHCsPX5kG_v-F-cjpyMQsT_b386eok=mqWW0%2BEUb_4-_1Otnw@mail.gmail.com> <20150115192624.122066dd@bender.lan> <CAFHCsPW5q=jMsehuYro7V5g56pMXK1tENP-_ibpg0q76LLWxJQ@mail.gmail.com> <20150116120315.7f343f66@bender.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_661B2A50-D00F-415F-8037-0334B40915D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jan 16, 2015, at 5:03 AM, Andrew Turner <andrew@fubar.geek.nz> =
wrote:
>=20
> On Fri, 16 Jan 2015 12:44:22 +0100
> Svatopluk Kraus <onwahe@gmail.com> wrote:
> ...
>> It's just a few things from quick look now which are different in our
>> design. However, my intention is not read our code on behalf of you. =
I
>> still think that our design is more general mainly and can serve for
>> interrupt controllers better.
>=20
> I was asking on the differences as I'm already in the process of
> importing the arm_intrng project branch as I need something like it on
> arm64. It is also based on the same code from Jakub and Ian, I haven't
> looked at changing the design, just cleaning up the code to import =
into
> head.
>=20
> I would be happy to merge your code instead, along with my existing
> cleanups, however I would need to know why I should spend time on it =
as
> opposed to the current development branch. If we do decide to with =
your
> change I would like to import it into the arm_intrng project branch
> first to assist the import into head.

My first look at Svatopluk=E2=80=99s code and summaries, on its surface =
it seems
to be a simpler, more generalized and more effective design than intern.
It avoids some additional overhead that=E2=80=99s always troubled me =
about intern
that I=E2=80=99ve not had the time to make good suggestions to overcome. =
It looks
(again on its surface) easier to bring to all the architectures as well.

I haven=E2=80=99t tried to use the code so I can=E2=80=99t comment on =
its stability. So of course
I can=E2=80=99t measure the differences in interrupt latencies between =
the two. Both of
these factors would be the kind of data that would help drive the =
decision of which
one to adapt.

Warner

--Apple-Mail=_661B2A50-D00F-415F-8037-0334B40915D6
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUuS+IAAoJEGwc0Sh9sBEAQLEQAJFGhkdV6qK95lokyahXiEPA
ccY4VevBONUAhWRvkvbqOj3lsxQFVxK3k6ddCe62Zd15+QsfmeiYTnGqfvZA6qaq
cR9F7LCpp2HxFvlrSTGxcSAHNxBdf4cKeWFqwtStv0gZsGfnkkbOeXp+cj9bvLQ5
x/2XptFXVT9wpQ46N90v1NDHbNryIMpYuTpPu3eAe8fEeeZoUzx7+tVQ4YJRkDpU
ckHXaWe6nwOGFKBoofvyulSbXVH7QlmaRyuZeDlVhpSfGanwRQOva2lmWyoeV0jg
l5S7pIUgajjHfvlBr3zZjo3MaE29TOe0efo6MM1eUhPM+aTdExG0pSXuKzKu6805
20fikLrVvvLKwfYxQm9hMiQClQQ58Rwe03jghBH5NU4reo9YZMdSVQCRkedWqxUV
xhy82qEHSy2eFti1flXA2TAldoS9dL1L24/BfCNKmqnJaHC+sLMpy2JCVDwFHcYK
SpYR8LzjxxK13KFxC9bQTu4Sae/i8CJ4RHaC0zepC9h2lXFFMvJeEC6+hxzGBqqW
SzR7teqvWj3j/1WkU/M0c0WBf6n0Tl6zi4MebPPF8K4n5cMvLLG5EIxJUD5jLHI1
h2GkrEdI7FFWwun2B7hQrw71RDaa4y4KsVffJ1mtz2Z/nJDn1Ew12QP5qpa4RBFG
fvH9/ekaEe6ngELz4lie
=+86/
-----END PGP SIGNATURE-----

--Apple-Mail=_661B2A50-D00F-415F-8037-0334B40915D6--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6E33C7B5-F784-4604-9F09-9FEDB1EFBE56>