public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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/
>
>  
>



  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