All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luben Tuikov <luben@splentec.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] SCSI Core cmd allocation 3/3
Date: Mon, 13 Jan 2003 14:16:48 -0500	[thread overview]
Message-ID: <3E2310A0.8080308@splentec.com> (raw)
In-Reply-To: 20030113175948.A27650@infradead.org

Christoph Hellwig wrote:
> 
> Well, where do you actually _need_ scsi_get_command(), that's the question.
> 
> I see the purpose, but I don't see it actually used.

The scsi devices discovery code *may* use it.

> Go and program in Smalltalk if you're a OOP fanatic.  Even if the kernel

I've had my share with C++.  You didn't have to be ironic, I was trying
to convey a point, which you're shooting down before even considering it.

> uses OOP paradigms where they are useful it uses procedural interfaces
> where they make more sense.  And in thjis case the OOP abstraction don't buy
> us anything.

The improperly conjucated phrase ``... don't buy us anything'' is
over-used in linux-kernel; why do it here as well?

>>It is my belief that such a struct will make things cleaner and clearer.
> 
> 
> But it's not a paradigm used in the linux kernel usually.

``There's always a first time.'' -- anonymous

If a global variable is used in a couple of files, belonging
to the same functionality, providing a unified service, and if
there's more than one of them, then they are better organized
as such as I've outlined.

In fact I'd argue that OOP is used exclusively *everywhere* in kernel
programming and specifically in the Linux kernel. It's an integral
part of organization of data, manipulators and ownership.
You name it, *anything* -- it's OOP. Files, filesystems, devices,
networking, etc, etc, etc.

> Kernel style is not just K&R.  i.e. your function descriptions should be
> converted to the extractable kernel-doc comments

/* fn_name: comment
    more comment
*/

This is the style K&R1 uses, from which I learned C, many, many years
ago...

I also thought that the kernel comment parser could recognize such
patterns, as they are not that hard to parse.

> and stuff like:
> 
> +       if (!dev) return NULL;
> +       if (!dev->host) return NULL;
> 
> doesn't even seem to be K&R to me :)

Christoph, please, this is an *inline* function -- it doesn't have to be
20 lines if it can be 10.

-- 
Luben




  reply	other threads:[~2003-01-13 19:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-07  0:37 [PATCH] SCSI Core cmd allocation 3/3 Luben Tuikov
2003-01-11 18:03 ` Christoph Hellwig
2003-01-13 17:12   ` Luben Tuikov
2003-01-13 17:59     ` Christoph Hellwig
2003-01-13 19:16       ` Luben Tuikov [this message]
2003-01-13 20:11         ` Patrick Mansfield
2003-01-13 20:40           ` Luben Tuikov

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=3E2310A0.8080308@splentec.com \
    --to=luben@splentec.com \
    --cc=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    /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.