From: "David B. Stevens" <dsteven3@maine.rr.com>
To: Helge Hafting <helgehaf@aitel.hist.no>
Cc: Jos Hulzink <josh@stack.nl>, linux-kernel@vger.kernel.org
Subject: Re: 2.7 (future kernel) wish
Date: Fri, 26 Dec 2003 18:57:45 -0500 [thread overview]
Message-ID: <3FECCAF9.7070209@maine.rr.com> (raw)
In-Reply-To: <20031226233855.GA476@hh.idb.hist.no>
While I agree that the kernel should provide decent error handling and
reporting I still have to ask questions about what is reasonable.
What does that other OS do when you pull a USB stick out? What do you
think the kernel should do? Why don't the applications operating on the
data take better care of handling error conditions?
I don't have one here to try, but at some point the (ab)user needs to
take a bit of the heat for his or her action(s) or lack thereof.
After all you could just reach in your case and rip out the IDE or SCSI
cables. Bet that leads to all kinds of stuff (tm).
Cheers,
Dave
Helge Hafting wrote:
>On Tue, Dec 23, 2003 at 11:42:17PM +0100, Jos Hulzink wrote:
>
>
>>Hi,
>>
>>First of all... Compliments about 2.6.0. It is a superb kernel, with very few
>>serious bugs, and for me it runs stable like a rock from the very first
>>moment.
>>
>>As an end user, Linux doesn't give me a good feeling on one particular item
>>yet: Error handling.
>>
>>What do I mean ? Well... for example: Pull out your USB stick with a mounted
>>fs on it.
>>
>>
>
>You aren't supposed to do that. If you want to pull devices like that,
>with no warning, access them in other ways than mounting.
>mtools are nice when you don't want to mount/umount floppies - a
>similiar approach should work for usb sticks too.
>
>
>
>Helge Hafting
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
next prev parent reply other threads:[~2003-12-26 23:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-23 22:42 2.7 (future kernel) wish Jos Hulzink
2003-12-26 23:38 ` Helge Hafting
2003-12-26 23:57 ` David B. Stevens [this message]
2003-12-27 6:51 ` Joshua Schmidlkofer
2003-12-28 3:03 ` Jim Crilly
2003-12-28 3:08 ` Kevin P. Fleming
2003-12-28 3:13 ` Rob Love
2003-12-28 11:17 ` Kevin Krieser
2003-12-28 11:23 ` Gaël Le Mignot
2003-12-28 3:11 ` Rob Love
2003-12-28 3:19 ` Jim Crilly
2004-01-04 21:05 ` Pat Erley
2003-12-28 3:57 ` Joshua Schmidlkofer
2003-12-28 4:33 ` Elladan
2003-12-30 14:20 ` Helge Hafting
2003-12-31 0:18 ` Jim Crilly
-- strict thread matches above, loose matches on Subject: below --
2003-12-30 15:41 Pacheco Jason NPRI
2003-12-30 16:18 ` mjt
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=3FECCAF9.7070209@maine.rr.com \
--to=dsteven3@maine.rr.com \
--cc=helgehaf@aitel.hist.no \
--cc=josh@stack.nl \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox