All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominik Brodowski <linux@dominikbrodowski.de>
To: Adam Belay <ambx1@neo.rr.com>,
	linux-kernel@vger.kernel.org, rmk@arm.linux.org.uk,
	akpm@osdl.org, rml@ximian.com, greg@kroah.com
Subject: Re: [RFC][PATCH] driver model and sysfs support for PCMCIA (1/3)
Date: Tue, 29 Jun 2004 21:09:48 +0200	[thread overview]
Message-ID: <20040629190948.GA8659@dominikbrodowski.de> (raw)
In-Reply-To: <20040628200224.GE5175@neo.rr.com>

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

Hi Adam,

First of all I'd like to say that I'm glad you're taking interest in 
the PCMCIA core, and that your experience and patch-writing skills will
surely be a valuable addition in the joint effort of transforming the 
PCMCIA subsystem to "kernel standards", e.g. hotplug, driver model and 
sysfs.

Second, you might not know about the linux-pcmcia list 
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
yet -- it's where most PCMCIA-core-in-2.{6,7} stuff is discussed, and it is quite
low-traffic. Please CC this list on PCMCIA-core-in-2.{6,7} matters in
future.

Third, about your patches:
- I like many ideas in your patches -- large parts of them, though, are
  "double work" as similar things have already been submitted (by me) 
  to Russell on the linux-pcmcia mailing list. What's missing in my current
  patches [proof-of-concepts do exist and had been announced both on lkml
  and on said linux-pcmcia list, though] is the exporting of product and
  manufactor ID and "vers_1" strings, because that needs better resource
  handling.
- the resource_ready handling is "racy", at least. Resources can disappear
  again.
- what I don't like in your patches is that they add an aditional "layer"
  and thus additional complexity on top of PCMCIA. It already has a multitude of
  structs with different lifetime rules. Your additions don't make it easier
  to simplify this complexity. That's why my patchsets [*] try to reduce the
  complexity first, add struct pcmcia_device next, and reduce complexity by
  merging other stuff into struct pcmcia_device in the third step. I'd need
  to re-check whether the step (1) you're leaving out does _not_ cause
  lifetime headaches and races in strange circumstances [and I don't mean
  PCMCIA net drivers here, as they're in a comparably good shape.]

	Dominik

[*] these patchsets have been announced in these messages:
1) http://lists.infradead.org/pipermail/linux-pcmcia/2004-May/000877.html
2) http://lists.infradead.org/pipermail/linux-pcmcia/2004-May/000878.html
3) http://lists.infradead.org/pipermail/linux-pcmcia/2004-May/000880.html
4) http://lists.infradead.org/pipermail/linux-pcmcia/2004-May/000881.html
5) http://lists.infradead.org/pipermail/linux-pcmcia/2004-May/000882.html

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2004-06-29 19:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-28 20:02 [RFC][PATCH] driver model and sysfs support for PCMCIA (1/3) Adam Belay
2004-06-29  5:57 ` Dmitry Torokhov
2004-06-29  8:46 ` Russell King
2004-06-29 19:09 ` Dominik Brodowski [this message]
2004-07-05 22:47   ` Adam Belay
2004-07-19  8:02     ` Dominik Brodowski
2004-07-26 13:53       ` Adam Belay
2004-07-27 18:27         ` Dominik Brodowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040629190948.GA8659@dominikbrodowski.de \
    --to=linux@dominikbrodowski.de \
    --cc=akpm@osdl.org \
    --cc=ambx1@neo.rr.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=rml@ximian.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.